On Wed, Feb 05, 2014 at 12:31:34PM -0800, Junio C Hamano wrote:

> Jeff King <p...@peff.net> 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

...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?).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to