Re: [PATCH/RFC] Convenient support of remote branches in git-checkout

[Junio C Hamano <junkio@cox.net>]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

>> Then "git checkout origin/next" would always mean "I want to
>> switch to the branch I use to hack on the branch 'next' Junio
>> has".  Do it once and you will get exactly my tip, hack on it,
>> switch out of it and then do it again and you won't lose your
>> previous work but just switch to that branch.
>
> Ah, now I understand your thinking.
> I admit it has a compelling elegance.
>
> However.
> Would it not be confusing for newbies (and not only for them) to
> first reference the remote branch with "origin/next", and afterwards, you
> get your own development branch by using the exactly same name?

When we get these per-branch attributes used widely enough, we
might add new vocabulary to our extended sha1 expressions that
denotes "the branch I forked this branch off of".

If refs/heads/next is created from refs/remotes/origin/next,
perhaps with an updated git-branch command that knows how to
help set things up, we might want to be able to refer to
remotes/origin/next as "next's upstream".  While we are on
'next' branch, we might want to refer to "HEAD's upstream".

I am not sure what the syntax for that should be, though.
Perhaps "HEAD@upstream"?

Unlike the regular extended sha1 expression modifiers such as
name~n, name^n, and name^{type}, it does not work with arbitrary
object name; it can only work with a refname.  Which is similar
to the '@{time}' notation we added when we started using
ref-log.  Strictly speaking these should not belong to the sha1
naming layer, but we can have them anyway for the user's
convenience.