Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> 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.
-
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