Re: [PATCH] pull, fetch: add --set-upstream option

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@matthieu-moy.fr> writes:

> To me, it depends on the involvement in the project. If I plan to send
> several contributions to a project, I'd usually clone the upstream and
> add my fork. But I also often do:
>
> - Find a project on GitHub/GitLab/...
> - Think about a minor contribution I can make
> - Fork from the web UI
> - clone my fork
> - code, commit, push
> - make a PR
>
> Only if my PR takes time to get accepted, I'll add upstream as a remote
> and pull from there to rebase my PR.

OK.

>>  - The second step adds the true upstream using "git remote", and at
>>    that point, in your mind you are quite clear that you want to
>>    pull from there (and push to your own fork).  Not having the "I
>>    am adding this new remote; from now on, it is my upstream"
>
> Note that you can also group "remote add" and "pull" by saying just
>
>   git pull --set-upstream http://example.com/project-main-repo master
>
> (I still tend to prefer the "remote add" + "pull" flow to name the
> remote, though).

I do too, and that's where my "shouldn't this feature be part of
'remote add' comes from.

> That wouldn't make the commands really easier to type IMHO, as you would
> still have to pull at some point, so it's:
>
>   git remote add main http://example.com/project-main-repo
>   git pull --set-upstream main master
>   
> Vs
>
>   git remote add --set-upstream master main http://example.com/project-main-repo
>   git pull
>
> The second is a bit shorter (saves the second instance of "master"), but
> I tend to prefer the first to avoid the overly long "git remote add"
> command.

I do not particularly care about five extra keystrokes.  The reason
I prefer the latter more is conceptual clarity of it saying "I use
'remote' to set things up, and then use 'pull' to get updated" (as
opposed to "I use 'remote' to set things half-way up, and then use
the first 'pull' to finish setting things up and getting updated.
I should remember that I do not need to give --set-upstream to later
'pull' I used to get further updates").

> Actually, since "--set-upstream" means "next time, *pull* from this
> branch", it felt weird to have it in "git *push*" and not in "git pull".
> Certainly, not having "git pull --set-upstream" it "git pull" wasn't
> that much bothering (otherwise, someone would have implemented it long
> ago), but I still find it a nice-to-have shortcut.

Yeah, I do not think 'push --set-upstream' is a great feature,
either, but since we have it already, I do not mind too much to have
another on the 'pull' side.  It just feels that we are piling band
aid for the lack of the right feature in the right command by adding
it to wrong command(s).