Re: git diff-tree commit detail bug in 2.0.2 and 2.0.3

From: Bryan Turner <bturner@atlassian.com>
Date: Jul 28, 2014, 12:08 UTC
Message-ID: <CAGyf7-GVz8ME0Mq_DyHCSFCx5KN6qLGEgtgMSv2NkKb9AGEGdg@mail.gmail.com>
In-Reply-To: <20140728104409.GC10737@peff.net>

On Mon, Jul 28, 2014 at 8:44 PM, Jeff King <peff@peff.net> wrote:

Show 27 quoted lines

> On Mon, Jul 28, 2014 at 06:35:04AM -0400, Jeff King wrote:
>
>> I haven't reproduced here yet, but this is almost certainly the bug
>> where lookup_unknown_object causes a bogus commit->index field (and
>> prior to the commit you found, diff-tree did not use commit->index).
>>
>> The series that Junio has in jk/alloc-commit-id should fix the problem
>> (it's in master already, and slated for v2.1.0).
>
> Yep, that's definitely it. Here's the minimum reproduction:
>
>   git init
>   git commit --allow-empty -m one
>   git commit --allow-empty -m two
>   git rev-list HEAD | git diff-tree --stdin --always --format=%s
>
> That yields:
>
>   one
>   one
>
> on v2.0.3, but merging in jk/alloc-commit-id yields:
>
>   two
>   one
>
> -Peff

Thanks for digging into it, Jeff. I should have tried it against 2.1.0 myself. I've run my entire matrix of tests now against 2.1.0-rc0 and the diff-tree bug appears fixed on that tag. I noticed a different change, though:

bturner@ubuntu:~/tmp/test$ /opt/git/2.1.0-rc0/bin/git check-ref-format ref/with/trailing/dot. bturner@ubuntu:~/tmp/test$ echo $? 0 bturner@ubuntu:~/tmp/test$ /opt/git/2.0.3/bin/git check-ref-format ref/with/trailing/dot. bturner@ubuntu:~/tmp/test$ echo $? 1

It looks like refs ending in a dot are now legal in 2.1.0? Is that
intentional? A quick git bisect is fingering:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
745224e04a03e4544c58d5d38d3c54f67100f8eb is the first bad commit
commit 745224e04a03e4544c58d5d38d3c54f67100f8eb
Author: David Turner <dturner@twopensource.com>
Date:   Wed Jun 18 01:54:42 2014 -0400

Best regards, Bryan Turner