Re: bug? in checkout with ambiguous refnames

From: Jeff King <peff@peff.net>
Date: Jan 12, 2011, 01:25 UTC
Message-ID: <20110112012515.GA30856@sigill.intra.peff.net>
In-Reply-To: <20110111180208.GC1833@sigill.intra.peff.net>

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

Show 14 quoted lines

> 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