Re: bug? in checkout with ambiguous refnames

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

quoted

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.

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