Re: bug? in checkout with ambiguous refnames

[Jeff King <peff@peff.net>]

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.

But it's not. Even taking away the die, my second test here fails (built
on top of the three previous commits under discussion):

diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
index e2b330b..7a6b30b 100755
--- a/t/t2019-checkout-amiguous-ref.sh
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -50,4 +50,13 @@ test_expect_success VAGUENESS_SUCCESS 'checkout reports switch to detached HEAD'
 	! grep "^HEAD is now at" stderr
 '
 
+test_expect_success 'new branch from ambiguous start_point works' '
+	git checkout -b newbranch ambiguity
+'
+
+test_expect_success 'checkout chooses tag over branch for start_point' '
+	echo tag >expect &&
+	test_cmp expect file
+'
+
 test_done

For bonus fun, doing this:

  git branch newbranch ambiguity
  git checkout newbranch

_does_ prefer the branch. So it is checkout feeding create_branch() the
modified sha1. I'll see if I can dig further.

-Peff