Re: bug? in checkout with ambiguous refnames

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2011, 07:31 UTC
Message-ID: <7v1v4m8reh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110108214011.GA4753@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 19 quoted lines

> On Sat, Jan 08, 2011 at 03:40:33PM -0500, Martin von Zweigbergk wrote:
>
>> > Yeah, we generally resolve ambiguities in favor of the tag (and that
>> > warning comes from deep within get_sha1_basic). So the real bug here is
>> > that it still said "Switched to branch", which is totally wrong.
>> > 
>> > That being said, it probably would make more sense for "git checkout" to
>> > prefer branches to tags.
>> 
>> What was the rationale for generally favoring tags?
>
> I don't recall hearing any specific argument, but it has always been
> that way from early on. I think it is from a vague sense of "tags are
> more important than branch tips because they are about marking specific
> points, not lines of development". But maybe other old-timers can say
> more.
>
> I don't necessarily buy that argument; my only reasoning is that we
> should probably keep historic behavior.

I don't think "tags are more important" has ever been a serious argument, either. We prefix refs/tags/ and refs/heads/ to see if what the user gave us is a short hand, and we have to pick one to check first, and we happened to have chosen to check tags/ before heads/. Majority of people have been trained by the ambiguity warning not to use the same name for their tags and branches, and the rest have learned to live with this convention.

Among those "rest who have learned to live with" minority are people who use v1.0 branch to maintain v1.0 codebase after it is tagged, and they would want to work on v1.0 branch (by checking out v1.0 branch) and measure their progress by disambiguating between heads/v1.0 and tags/v1.0 when driving "git log" family. There is no strong reason to forbid them from doing this by requiring uniqueness if that is what they want, although I personally would suggest them to use maint-1.0 branch that forks from v1.0 tag.

Aside from your "'checkout branch' is about checking out a branch" explanation, there are two reasons to favor branches over tags in "checkout" command:

 (1) You cannot disambiguate "git checkout heads/master" when you have
     "master" tag, as this notation is used to tell the command "I want to
     detach HEAD at that commit"; and

 (2) The command already treats an unadorned branch name specially by not
     complaining ref/path ambiguity when you said "git checkout master"
     and you have a file called "master" in your working tree, so users
     already expect that an unadorned branch name is special to it.