Junio C Hamano <gitster@xxxxxxxxx> wrote: > Given an existing .pack file and the .idx file that describes it, > this new mode of operation reads and re-index the packfile and makes > sure the existing .idx file matches the result byte-for-byte. > > All the objects in the .pack file are validated during this operation as > well. Unlike verify-pack, which visits each object described in the .idx > file in the SHA-1 order, index-pack efficiently exploits the delta-chain > to avoid rebuilding the objects that are used as the base of deltified > objects over and over again while validating the objects. This should > result in much quicker verification of the .pack file and its .idx file. > > This version however cannot verify a .pack/.idx pair with a handcrafted v2 > index that uses 64-bit offset representation for offsets that would fit > within 31-bit. You can create such an .idx file by giving a custom offset > to --index-version option to the command. > > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > > * This does not make much of a difference in a small project like git.git > itself, especially when the repository is packed with not very big depth > value. However it is useful on larger repositories, like linux-2.6. I'd like to see this series cleaned up and submitted, because as Peff's tests shows, it shaves 1 minute off the linux-2.6 fsck. Skim reading the code it mostly looked OK, though the NEEDSWORK stuff has to be cleaned up. And I wonder if the series cannot be flipped around a bit to put the 4/5 earlier and try to avoid a stage where `index-pack --verify` doesn't do the right thing on the hand-rolled lower 32 bit index limit. In this patch I'm not happy about csum-file having this check_fd part of its contents. But its probably the shortest way to inject validation into index-pack without butchering a large part of its index generation function. -- Shawn. -- 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