On Wed, Feb 05, 2014 at 12:31:34PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > The minimal fix you posted below does make sense to me as a stopgap, and > > we can look into dropping the code entirely during the next cycle. It > > would be nice to have a test to cover this case, though. > > Sounds sensible. Run "repack -a -d" once, and then another while > forcing it to be single threaded, or something? Certainly that's the way to trigger the code, but doing this: diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh index b45bd1e..6647ba1 100755 --- a/t/t7700-repack.sh +++ b/t/t7700-repack.sh @@ -162,7 +162,12 @@ test_expect_success 'objects made unreachable by grafts only are kept' ' git reflog expire --expire=$test_tick --expire-unreachable=$test_tick --all && git repack -a -d && git cat-file -t $H1 - ' +' + +test_expect_success 'repack can handle generating the same pack again' ' + git -c pack.threads=1 repack -ad && + git -c pack.threads=1 repack -ad +' test_done ...does not seem to fail, and it does not seem to leave any cruft in place. So maybe I am misunderstanding the thing the patch is meant to fix. Is it that we simply do not replace the pack in this instance? I guess we would have to generate a pack with the identical set of objects, then, but somehow different in its pack parameters (perhaps turning off deltas?). -Peff -- 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