Re: [PATCH] repack.c: rename and unlink pack file if it exists
On Wed, Feb 05, 2014 at 03:37:40PM -0500, Jeff King wrote:
Show 12 quoted lines
> > 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:
> [...]
> ...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?).
Here's a more robust test that actually checks the pack contents:
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index b45bd1e..c18a318 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -164,5 +164,17 @@ test_expect_success 'objects made unreachable by grafts only are kept' '
git cat-file -t $H1
'
+test_expect_success 'repack can handle generating the same pack again' '
+ show_deltas() {
+ git rev-list --objects --all --reflog |
+ git cat-file --batch-check="%(objectname) %(deltabase) %(rest)"
+ }
+ git -c pack.threads=1 repack -adf --window=0 &&
+ show_deltas >no-deltas &&
+ git -c pack.threads=1 repack -adf --window=10 &&
+ show_deltas >deltas &&
+ ! test_cmp no-deltas deltas
+'
+
test_done
which _also_ does not fail. And then I realized it is because of
1190a1ac, which gives these two separate names.
So I am not sure if it is even possible to trigger the bug in a
meaningful way at this point.
-Peff
Jeff King <peff@peff.net>