Re: bug? in checkout with ambiguous refnames

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 11, 2011, 17:02 UTC
Message-ID: <7vvd1v4bmt.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110111065207.GF10094@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 23 quoted lines

> On Fri, Jan 07, 2011 at 03:17:22PM -0800, Junio C Hamano wrote:
>
>> ... And this comes on top (should probably be squashed into one) to really
>> favor a branch over a tag.
>> 
>>  builtin/checkout.c               |   26 ++++++++++----------------
>>  t/t2019-checkout-amiguous-ref.sh |    2 +-
>>  2 files changed, 11 insertions(+), 17 deletions(-)
>
> Yeah, that looks sane to me (assuming all three patches squashed
> together). It took me a minute to figure out one subtlety, though:
>
>> +		if ((check_ref_format(new.path) != CHECK_REF_FORMAT_OK) ||
>> +		    !resolve_ref(new.path, rev, 1, NULL))
>> +			new.path = NULL; /* not an existing branch */
>> +
>> +		if (!(new.commit = lookup_commit_reference_gently(rev, 1))) {
>
> We are relying on the fact that resolve_ref leaves "rev" alone in the
> case that it does not find anything. Which is mostly true (the only
> exception seems to be if you have a ref with non-hex garbage in it, in
> which case you will get some bogus sha1 in the output). I dunno if it is
> worth making it more explicit, like:

I've thought about it when I sent the patch. I think this is safe as that particular resolve is done on a full ref "refs/heads/$something" and upon seeing the first 'r' get_sha1_hex() would give up without touching rev[], but I agree it is too subtle.

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

> I was surprised to find that the current behavior is to die(), due to an
> explicit case in branch.c:create_branch.

Good eyes. At that point, "refname <start> is ambiguous." warning has already been issued, and there is no sane reason to die there. I'd call it a bug.