magithub icon indicating copy to clipboard operation
magithub copied to clipboard

magithub-clone should handle cloning forks

Open vermiculus opened this issue 8 years ago • 6 comments

From #130. When cloning a fork, we should in fact clone the source repository and then add the fork as a remote (and set up defaults, etc.) One question that remains is whether to use the parent repo (that repo from which the current repo was forked) or the source repo (that repo from which all forks originate).

vermiculus avatar Aug 27 '17 15:08 vermiculus

I think we should treat original parent repo as upstream remote.

stardiviner avatar Sep 29 '17 10:09 stardiviner

@stardiviner I think that's the plan. I really need to get back to work on this project :wink: There's handling for this now; I just need to polish and publish.

vermiculus avatar Sep 29 '17 13:09 vermiculus

Coming back to this since it came up while writing documentation. Is there a strong reason for not cloning the source repository and then adding the fork as a normal remote? It would work with the other tools a lot better.

vermiculus avatar Jan 26 '18 05:01 vermiculus

My most working forks are Emacs packages, on very little case, if the original author late to accept PR, or not maintaining, like arduino-mode. I usually will fork, then use use-package-quelpa to use my own fork as package source. Almost every case if I want to PR, I will create a fork at first.

stardiviner avatar Jan 26 '18 08:01 stardiviner

Yes, and your fork is really just a branch of the source to be merged into its base. Is there any difference between having

[upstream]
   url = path/to/source.git
[origin]
   url = path/to/fork.git
[branch "new-feature"]
   remote = origin

and

[origin]
   url = path/to/source.git
[stardiviner]
   url = path/to/fork.git
[branch "new-feature"]
   remote = stardiviner

?

vermiculus avatar Jan 26 '18 12:01 vermiculus

Ah, you're right, no different. I have not realized that. That's a bad habit now. :)

stardiviner avatar Jan 26 '18 13:01 stardiviner