Re: bug? in checkout with ambiguous refnames

[Jeff King <peff@peff.net>]

On Tue, Jan 11, 2011 at 01:02:08PM -0500, Jeff King wrote:

> On Tue, Jan 11, 2011 at 09:02:18AM -0800, Junio C Hamano wrote:
> 
> > > Also, one other question while we are on the subject. I think we all
> > > agree that "git checkout $foo" should prefer $foo as a branch. But what
> > > about "git checkout -b $branch $start_point"?
> > 
> > That has always been defined as a synonym for
> > 
> > 	git branch $branch $start_point && git checkout $branch
> > 
> > so $start_point is just a random extended SHA-1 expression.
> 
> That's what I would have expected, but I wanted to write a test to make
> sure it was the case.

Looking into this more, I'm not sure what the right behavior is. The
offending lines are in branch.c:create_branch:

        switch (dwim_ref(start_name, strlen(start_name), sha1, &real_ref)) {
        case 0:
                /* Not branching from any existing branch */
                if (explicit_tracking)
                        die("Cannot setup tracking information; starting point is not a branch.");
                break;
        case 1:
                /* Unique completion -- good, only if it is a real ref */
                if (explicit_tracking && !strcmp(real_ref, "HEAD"))
                        die("Cannot setup tracking information; starting point is not a branch.");
                break;
        default:
                die("Ambiguous object name: '%s'.", start_name);
                break;
        }

The die("Ambiguous...") blames all the way back to 0746d19 (git-branch,
git-checkout: autosetup for remote branch tracking, 2007-03-08) and
seems to just be a regression there that we didn't catch.

Obviously we can loosen the die() there and just handle the ambiguous
case like the unique case. But I'm not sure how tracking should interact
with the branch/tag thing.

This code seems to be trying to only track branches, but it fails at
that. It actually will track _any_ ref. So I can happily do:

  git branch --track foo v1.5

and start tracking refs/tags/v1.5. Is that a bug or a feature?

And then that makes me wonder. What should:

  git branch --track foo ambiguity

do? Should it choose the branch, because that is more useful for
tracking? Or choose the tag? And if branch, then what should:

  git branch foo ambiguity

do? It won't track a tag unless --track is given explicitly. Should it
prefer a branch with implicit tracking, or an untracked tag?

I'm not sure. And to be honest I don't really care, because I think
people with ambiguous refs are little bit crazy anyway (after all, in
the current code it simply calls die()). But I think there is some
argument to be made that due to tracking, start_point is not _just_
a regular ref. We do care about its branchiness.

-Peff