There's already an API for GitHub issues, but has anyone succeeded in making it two-way? That is:
git clone git#github.com:user/repo.issues.git # Like for wiki
editor repo.issues/1.json
git push -u origin master
And voilà, a new/updated issue #1!
It could use a pre-receive hook to validate before accepting any pushes, so invalid formatting shouldn't be a problem.
In other words, is there some way to handle the issues of a GitHub project as another GitHub repo?
Aside from using the API, I don't see how this can be done cleanly.
You could put together a (custom) monstrosity that updates a separate GitHub repo with all the issues in said repo at a predefined interval (using the API), but given the effort involved, this better be worth it to you :)
Related
I created a pull request on GitHub and, after receiving comments, I would like to add more commits to it, by modifying different files.
Is it possible to do it with a Web browser only, without access to the git command?
Also, consider that I am not the owner of the repository.
Note that the answers to the question github: Adding commits to existing pull request
do not address my question, as they use git, or deal with changing a single file.
We are using AWS Code Commit for source code and considering moving to Github in the near future. What is the easiest way to accomplish this ? I have seen a lot of articles about importing a Github project into AWS Code commit but not the other way around.
Simplest way is to clone your code commit repo and push it to your GitHub repo.
I think this is a very fair question and none of the comments have addressed it. Though it is trivial to migrate the git repo, that is not a full clone of all meta data related to it. This is roughly:
git clone --mirror <source repo>
Create new, empty repo in a GitHub org you can write to
git add remote target <dest repo>
git push --mirror target
What gets missed doing git migrations like this is things such as users/groups permissions, pull requests, secrets, and probably other things I've forgotten. This meta data is not stored in the git repo and needs to be re-implemented on the GitHub side. As there are usually APIs to the Git systems, migration scripts can be written and some are written by GitHub, some by individuals (though I struggled to find any active examples).
I too have searched extensively for a migration tool that actually gets all the data for an AWS CodeCommit repo and reproduces it as a GitHub repo.
It looks like I should be able to write a script that uses the AWS REST API to get the data and then write it to the GitHub API. I was hoping this code already existed and I would save a bunch of time writing and debugging it.
As my browser was crashing I was not able to create a pull request from GitHub UI, I was trying to create a pull request from git console but didn't found any way to create a pull request.
I have also searched for the same over the net but most of the tutorials suggested to create a pull request from UIs only. I just want to be able to handle the pull request like creation, rejection, approved and merging without the browser. Please suggest.
git and github are separate products. github is a service that happens to use git, but it is not part of git, its UI is not a git interface, and git does not have any special support for github functionality.
There is a little potential confusion here, because there are "pull requests" - an integrated feature of github having to do with branch workflow - and there is git request-pull, a seemingly lesser-known feature of git which creates a text message you could send to another repository maintainer to request that they pull changes from your repository.
Naming confusion aside, the "pull request" you want is a feature of github, not git; and so git itself (including git console and any git UI tool) have no command for this. You have to use a github-supplied interface, and AFAIK that means the web UI.
To open a pull request from the command line, you can install the hub set of command-line tools that GitHub supports. This will allow you to create a pull request from a repository with:
hub pull-request
I'm not aware of any similar tools for managing pull requests, though.
git add -p
then
git commit -m "message"
then
git push origin "your_branch"
the pull request will be created in github
How can I make GitHub forget or disassociate that my repo was originally a fork of another project?
I forked a project in GitHub. I can now see "forked from whatever/whatever". The parent repository "whatever/whatever" is no longer maintained. I have been allowed to continue use of the code base of the original repository to create an independent repository.
Is there a way to detach my project from the original repository?
Update Jan 2022:
Use the GitHub chatbot-virtual-assistant at https://support.github.com/contact?tags=rr-forks&subject=Detach%20Fork&flow=detach_fork
First answer:
You can contact github support and ask them to switch your repository to "normal mode".
On this page, "Commit was made in a fork" paragraph, it is explained that one has to go through support to switch. Therefore, it is likely that there is no way to do that by yourself (unless you destroy and recreate your repo which is explained before... if you do so be careful if you have tickets or a wiki attached to your project as they will be deleted!).
You could duplicate the forked repository to a new repository (without the fork dependency) from the GitHub UI, then remove the original forked one:
Sign in to GitHub
Select the + sign in the top right corner and select Import repository.
Import your forked repository. The new repository won't have the fork dependency.
Delete the original, forked repository in the repository settings.
NOTE: This approach will not preserve issues and pull requests.
Make sure you have all the important branches and tags on your local repo, delete the github repo, recreate the repository through usual means (no forking) and push the local repository back with git push --all. Note that if you have local branches that you don't want to publish, might be worth to create a temporary clean local clone for the operation.
However, this will also get rid of wiki and issues. As the wiki is in fact it's own repository, it can be handled similarly by cloning it and then recreating and pushing. The repo address is on wiki's Git Access page (git#github.com:user/repo.wiki.git).
This leaves issues. They can be exported through the API, but as far as I know, you can only create issues and comments with your person, so importing them perfectly is impossible.
So, if you need issues to be preserved, you should go through github support as Thomas Moulard suggests.
I got the similar problem, and ended up using this github help page to solve it. I didn't mind about the wiki and issues tracker as it was for my blog using a theme kindly developed by another user.
To detach a forked repo and use it as your own after several commits without losing the whole history:
git clone --bare git#github.com:user/forked_repo.git
Create a new empty reposity new-repository on the github website.
And push a mirrored version:
cd user.github.com.git/
git push --mirror git#github.com:user/new-repository.git
One can rename on github, the forked_repository with another name to keep it as backup and check updates if needed. Or simply delete it.
Renaming the new-repository to the original name does the job. As a side effect, your commits now appear in your history.
Log in to GitHub with your credentials.
Go to https://support.github.com/contact?tags=rr-forks&subject=Detach%20Fork&flow=detach_fork.
Choose "Detach", then enter the URL or repo name of the fork as your-user-name/repository-name, and answer the other questions of the virtual assistant.
You will get an email with a ticket number where you can check the status of your request. You will also be notified per email once your repo has been deforked.
Most repository settings will stay unchanged, including user permissions, stargazers, issues, PRs, discussions, etc.
Using the info from aurelien and Clayton, I was able to do this with the following:
$ git clone --bare https://github.com/my/forked_repo.git
<delete forked_repo on GitHub>
<recreate repo on GitHub using same name>
$ cd forked_repo.git
$ git push --mirror
Here's the documentation for git clone --bare:
Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git, make the <directory> itself the $GIT_DIR. This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/. When this option is used, neither remote-tracking branches nor the related configuration variables are created.
Here's the documentation for git push --mirror:
Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.
Note: like the other git based answers, this will not copy over issues that are not part of the git repo such as the wiki and issues. Per Tapio:
The wiki is a separate git repo and can be handled in a similar fashion per Tapio. The address is: git#github.com:user/repo.wiki.git.
Issues can be exported via the GitHub API but there are issues recreating them since they can only be created by your user, so imports will lose information.
This only applies to GitHub Enterprise, not on github.com
Logged in to an account that has admin privileges:
Go to the repository that you need to detach: https://<ghe url>/<org>/<repo>
Click on the “Site Admin” rocket on the top right corner
Click "Collaboration" on the top menu bar
Click on “Network” on the left pane
Click on “Make Root” in the Network Structure pane
Accept
This was tested on GitHub Enterprise 2.9
If you do not need any past commits (I didn't in my case), you can just:
fork the project
make a local copy of the fork (I used my IDE to do that)
delete the git folder from your local copy
commit the project as you normally would a new project.
You can just delete the fork from your github account after. Took me all of one minute and worked like a charm.
I have a set of documentation for my company's API, based on the excellent Slate framework from TripIt. Per instructions, I forked their repo and proceeded to customize it. That fork lives here.
The obnoxious thing is that when contributors in my organization do a new pull request, the "base fork" on the Github "Comparing Changes" screen defaults to TripIt's repository, not my fork. They've more than once sent pull requests to the wrong place. Telling people "don't do that" isn't a particularly reliable solution. How can I set the default for where PRs are based to my fork?
GitHub keeps track of forks made through their interface and assumes pull requests will be for that original repository. You need to tell GitHub that your copy is not a fork but rather a regular repository that just happens to have identical history. Sadly, GitHub doesn't offer a good way to just uncheck the fork link. I typically solve it this way:
Clone the repository, git pull, and ensure your local copy is completely up to date.
Delete the repository on GitHub.
Create the repository on GitHub using the exact same name. Ensure it's an empty repository (don't create a README or LICENSE file.)
git push all the content back into the repository. (You may need to switch to each branch and push it, and you also may need to git push --tags.)
FRAGILE: This approach will lose existing GitHub issues and pull request comments. If you're using these heavily, this approach is probably a bad idea, and you should contact GitHub customer support to help you instead.
It is unfortunate that GitHub does not provide a way to configure the default PR target repo.
If you can delete (or get the owner to delete) the original repo A from which B was forked, then that will do the trick.
If it is not possible/agreeable to delete A, but the owner of A is willing to do the following, then the fork link gets broken, on GitHub Enterprise at least:
mark repo A as Private
mark repo A as Public again
After doing this, repo B (which was originally forked from A) will default to opening PRs against itself, rather than A.
Note: if A itself was forked from something further back in the history, then unfortunately it seems that B starts defaulting to opening PRs against that repo once A has gone. The only solution would be to apply the above to all repos upstream in the fork tree :(
Your other developers seem to have forked TripIt's repository, so that is the source/parent of their work.
In fact, if you open your own repository, you will see it hasn't been forked at all (the fork count is 0).
When they issue a merge request, by default github shows that repository as source, and so the pull request isn't sent to you.
The simplest workaround in this case is to ask your dev's to fork your repository, and work on it.
Yes, it's a bad situation...
The only solution I know of (other than deleting the fork and recreating/pushing directly from a local clone as described here ) is to have the upstream owner make the original repo PRIVATE and then return it to PUBLIC. Taking it private breaks the link to forks permanently.
But of course that requires action by the upstream owner. Github should really solve this, but it's been an issue for a very long time.