Re: [PATCH] repack.c: rename and unlink pack file if it exists

[Jeff King <peff@peff.net>]

On Wed, Feb 05, 2014 at 03:37:40PM -0500, Jeff King wrote:

> > 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