Submit patch to Github project without cloning repository to Github?

Question

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?

Answer 1

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 origin by 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 protected]: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

Answer 2

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 [email protected]:<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.

Answer 3

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.