Jeff King <peff@xxxxxxxx> writes:
> 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.
--
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