On Thu, 17 Feb 2011, Martin von Zweigbergk wrote:
Sorry, sent by mistake (wrong key).
> On Wed, 16 Feb 2011, Junio C Hamano wrote:
>
> > 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}
What I meant to say was that I'm not sure I agree that the point of
the @{upstream} notation is to hide the refs/remotes hierarchy. At
least to me. I think more important is having a single way to refer to
the upstream, whatever its value may be.
> >
> > 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.
Anyway, I agree with with this part. And I'm happy Johan adding the
"upstream" alias.
/Martin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html