hub remote add should offer an option to set the remote name manually

[sgallagher]

One common pattern I follow is to fork a project's repository, clone it under my own name (or "origin") and then add a remote called "upstream" for the original repository.

This is useful, because I can then use exactly the same command in any of my projects to rebase or merge from the original project (git rebase upstream/master or git merge upstream/master) and not have to vary the remote name for each checkout.

Could you add a -n NAME parameter to hub remote add so that it would be easy to do this?

[mislav]

How about treating the name "upstream" specially, so simply hub remote add upstream will figure out what's the parent of your fork and add the URL for it?

There was a number of feature requests for better remote naming re: "origin" vs "upstream": #798 #811 #762. I'm starting to be convinced that fork should set up the "origin" repo to point to your fork, and "upstream" to point to parent repo. Also, clone could by default create an "upstream" remote, unless you're cloning a fork, in which case it clones it to "origin" remote but also sets up an additional "upstream" remote.

Decisions, decisions… Which of these options would you prefer?

[sgallagher]

@mislav

Well, purely selfishly I very much like the idea that fork would automatically create "origin" pointing at your own name and "upstream" to the place you had forked from, since this describes my personal workflow exactly.

I don't think that hub clone should necessarily create "upstream" as the default name. I'd think that should probably stay closer to the git clone behavior of returning the remote name "origin" unless otherwise specified (with -o NAME). However, automatically creating a remote called "upstream" if the repo in question was forked from somewhere else would be really quite handy. Of course, the harder question there might be "What do we do if we have created a fork of a fork?".

Possible answers:

1. Set upstream to be the "master" copy, recursively tracking through the forks.
2. Set upstream to only be the immediate parent.
3. Set upstream to the parent only if there is no recursion. Otherwise, do not attempt to figure out what the user would prefer and create only the "origin" remote.

If I was implementing it myself, I'd probably go for 3), possibly implementing a non-default option for 1) and 2) somewhere down the line.

[mislav]

It's an interesting question about fork of a fork. I would just go for 2) and do immediate parent. These cases will probably be rare anyway, so if the person really wanted top-level parent instead, they can easily change that manually.

[sgallagher]

Yeah, that's true. Works for me.

[kbrock]

+1 for 2) - if you wanted to fork the upstream one, you would fork that one (and then add the child as a remote

[mislav]

Automatically adding an upstream remote when cloning a fork will be fixed by #1977