Re: bug? in checkout with ambiguous refnames

From: Jeff King <peff@peff.net>
Date: Jan 8, 2011, 21:40 UTC
Message-ID: <20110108214011.GA4753@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.1.10.1101081449220.12031@debian>

On Sat, Jan 08, 2011 at 03:40:33PM -0500, Martin von Zweigbergk wrote:

Show 8 quoted lines

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

> Why does that reasoning not apply to 'git checkout' too?

Because checkout has always been fundamentally about branches. It did end up growing sane behavior for "git checkout tag" (i.e., a detached HEAD), but branches are still the fundamental unit for most of its arguments.

> Btw, what exactly does "generally" mean, i.e. which other commands
> don't favor tags? I know rebase is one example of a command that does
> not favor tags.

It means "we favor tags in resolve_ref, which is the underlying machinery for most commands, so unless a command special-cases it, that will be the behavior, and I am too lazy to exhaustively search for such special cases".

> Slightly off topic, but why does 'git rev-parse --symbolic-full-name'
> not output anything when the input is ambiguous? 'git rev-parse'
> without any flags favors tags, so I would have expected to get
> something like refs/tags/$name back.

I dunno. I never tried it, but I would have expected to get the tag-name back.

Show 7 quoted lines

> The reason I'm asking is because I just happened to see in the rebase
> code the other day that it will rebase a detached head if the <branch>
> parameter is not "completely unqualified". For example 'git rebase
> master heads/topic' or 'git rebase master refs/heads/topic' will not
> update refs/heads/topic. I was trying to fix that by using 'git
> rev-parse --symbolic-full-name' to parse <branch>. That seemed to work
> fine until I saw this thread :-).

Heh. I think that would be an argument in favor of changing rev-parse's behavior.

-Peff