Re: [PATCH] push.default: Rename 'tracking' to 'upstream'

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

Sverre Rabbelier <srabbelier@gmail.com> writes:

> On Wed, Feb 16, 2011 at 10:26, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> I think that for 'branch.<name>.upstream' it would make more sense to
>
> I like the idea of naming it 'upstream', although I don't care much
> either way for restricting what you specify. I've always thought
> 'merge' was a curious name that didn't really fit with my mental model
> of what I was configuring.

That pretty much comes from the days back when 'merge' was the only method
of integrating with what the other party did.  

I agree "upstream" is a better name.  The name "merge" is about what
operation uses it, and does not say why it is used (i.e. "we merge with it
because it is _the other end_ of the integration"); the latter is a more
important thing to express.

Until another method of integration (namely, rebase) started using the
same mechanism, this was Ok, but when it happend, the name "merge"
immediately stopped making sense, but we did not rename nor give a synonym
to the variable.

The name "upstream" prepares us for yet another method of integration that
nobody has invented yet.

As to its value being what the other end calls the source, I think it is
not a good idea to change it, and it is even a worse idea to add a new
configuration variable that points into the tracking branches on our side.
@{upstream} is a short-hand notation to call the tracking branch of the
"upstream" we have been discussing, and has to point at refs/remotes/
hierarchy, but the entire point of the notation is that the users do not
have to see/type "refs/remotes/" when they say

    $ git merge @{upstream}

but at the level of an end-user's world-view, his branch that was forked
from origin's "master" integrates with origin's "master", and the use of
an intermediary, the refs/remotes/origin/master remote tracking branch
that is kept on the local side, is a mere implementation detail.

IOW, I consider --set-upstream that takes refs/remotes without bothering
to go through the remotes.<name>.fetch mapping is a design bug (it may
have come from sloppy initial coding---it certainly is easier to store
what you get without computing anything).  That may be something we might
want to fix in 1.8.0.