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

Josef Weidendorfer [off-list ref] writes:

quoted

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.

On Tuesday 07 November 2006 03:27, Junio C Hamano wrote:

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"?

I remember an idea floating around was to use a virtual
branch "ORIGIN" which always maps to the upstream of the current
branch.
 

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.

Yes, this makes sense. Branch relations like "upstream" is a
local configuration issue, similar to reflogs.

I vote for "HEAD@up", short form "@up".