Submit patch to Github project without cloning repository to Github?
I have a local repository that is a full copy of a repository on Github. I made a change that I would like to contribute to the original project.
How can I do this without reloading my project on Github? I don’t think opening an issue is the right way..
I saw in How can I contribute a patch to github? that I should fork the project, but since my local repository is “linked” to the original Github repository, I don’t want to mess it up.
So, if it is really discouraged to share the patch in any way but fork, how can I simply fork the original project, merge my changes, and then share them with the original repository?
If I delete the fork after I “committed” the change but it isn’t accepted yet, does my commit disappear?
4 Solutions collect form web for “Submit patch to Github project without cloning repository to Github?”
You should fork the project, yes. However, this does not mean you need to clone the whole stuff again locally.
Explanation: a simple way of looking at a git repository is a graph of commits (it is directed and acyclic but that is irrelevant for this discussion); and all nodes of this graph, ie the commits, have a unique identifier across all git repositories in the world. As to branches, they are just symbolic references to a commit (in git parlance, a branch — or a tag — is called a refspec).
Also, you are never linked to a remote repository in any way. The only thing you are really “linked to” is the commit graph. A remote repository just happens to have a set of refspecs (branches, tags)… pointing to a commit graph, which they also have — nobody likes dangling references. When you clone a repository, you get the commit graph (and associated trees) and the set of refspecs (ie branches, tags). A refspec points to a tree. And that’s about it.
This means the following:
- you have the original github repo: a graph of commits and associated trees, a set of refspecs;
- you have cloned it locally: the same graph of commits and associated trees, the same set of refspecs;
- you have committed stuff locally: you have added upon this graph and associated trees, and added a new set of refspecs.
OK, now do the following:
- clone the original repo on github: the same graph of commits and trees as the original; the refspecs are here, only preceded with the remote name, which is
originby default. And what now?
- on your local repository, add your fork as a remote;
- push to that fork (this will push the refspecs, and trees);
- submit a pull request.
Adding your fork as a remote is as “simple” as:
git remote add myfork email@example.com:youruser/theproject
Push your refspec (branch) to it:
git push myfork mybranch
And then submit a pull request to the original author.
It should be noted that in theory, you can add a remote to a git repository which has no relevance at all with the “original” repo: this is simply that the two commit graphs will be completely disjoint from one another — however, the use cases for this are rare
Yes, you should fork the project, but there’s no need to clone/pull/merge anything. After you click the fork button, do
git remote add yourfork firstname.lastname@example.org:<yourname>/<project>.git
and push your branch to your fork with
git push yourfork branchname
then issue a pull request.
If you delete the fork after the patch is merged by upstream, there should be no problem. I’m not sure what happens when you remove your fork before that happens.
There’s no need to merge anything.
You can always send a patch file to the maintainer by e-mail. The Linux kernel has been crafted that way for a very long time.
Without fiddling with your current copy of the repository.
- Create the patches with
- Fork upstream and clone it, but don’t replace your working copy.
- Apply the patches with
git amto the newly forked project, push them and create the merge request.
This is not the nicest solution, but it prevents you from accidentally loosing your changes.