On Mon, Jul 28, 2014 at 8:44 PM, Jeff King <peff@xxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxxx> Date: Wed Jun 18 01:54:42 2014 -0400 Best regards, Bryan Turner -- 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