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