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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 7, 2006, 02:27 UTC
Message-ID: <7vvels6lf4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200611070225.24956.Josef.Weidendorfer@gmx.de>

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

Show 13 quoted lines

>> 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.