On Sun, Aug 14, 2016 at 09:09:19PM +0200, Greg KH wrote: > Huh? Ok, this odd: > $ git describe --contains 8556e8f3b6 > fatal: cannot describe '8556e8f3b6c4c11601ce1e9ea8090a6d8bd5daae' > > Yet just a plain 'git describe' does work... > > That's what threw me off, I only use --contains as that shows the > release the commit is in. > > Ok, that makes me feel a bit better (that my scripts didn't miss the > patch, it was just old), but I wonder what is going on with git... Yeah, that's partially my fault. Back in 2009, I was using a version of guilt (quilt for git) that didn't enforce the requirement that within a particular linear sequence of commits, the Committer time must be always be increasing. In other words, things like this are never supposed to happen: % git log --pretty="%h %ci %s" -7 e8134b2 e8134b2 2009-01-05 21:38:26 -0500 ext4: Fix race between read_block_bitmap() and mark_diskspace_used() 5d1b1b3 2009-01-05 22:19:52 -0500 ext4: fix BUG when calling ext4_error with locked block group b7be019 2008-11-23 23:51:53 -0500 ext4: Fix lockdep recursive locking warning 7a2fcbf 2009-01-05 21:36:55 -0500 ext4: don't use blocks freed but not yet committed in buddy cache init fb68407 2008-11-06 17:50:21 -0500 jbd2: Call journal commit callback without holding j_list_lock c3a326a 2008-11-25 15:11:52 -0500 ext4: cleanup mballoc header files 920313a 2009-01-05 21:36:19 -0500 ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize ... because it hopelessly confuses commands like "git describe". As you have rediscovered. :-) The guilt command was fixed a long time ago to not do this thing, but the nasty commits from late 2008 and early 2009 are still in the tree. Fortunately, it's rare that we need to refer to commits this old, and so people don't run into this often. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
