Re: [PATCH] repack: respect gc.pid lock

From: Jeff King <peff@peff.net>
Date: Apr 18, 2017, 17:50 UTC
Message-ID: <20170418175011.qx64luolrvqwwtpa@sigill.intra.peff.net>
In-Reply-To: <710ded65bb8843ab838d9c52cd796317@exmbdft7.ad.twosigma.com>

On Tue, Apr 18, 2017 at 05:43:29PM +0000, David Turner wrote:

Show 15 quoted lines

> > A lock can catch the racy cases where both run at the same time. But I think that
> > even:
> > 
> >   git -c repack.writeBitmaps=true repack -Ad
> >   [...wait...]
> >   git gc
> > 
> > is questionable, because that gc will erase your bitmaps. How does git-gc know
> > that it's doing a bad thing by repacking without bitmaps, and that you didn't
> > simply change your configuration or want to get rid of them?
> 
> Sorry, the gc in Gitlab does keep bitmaps.  The one I quoted in a previous 
> message  doesn't, because the person typing the command was just doing some 
> manual  testing and I guess didn't realize that bitmaps were important.  Or 
> perhaps he knew that repack.writeBitmaps was already set in the config.

Sure, but I guess I'd just wonder what _else_ is different between the commands (and if nothing, why are both running).

> So given that the lock will catch the races, might it be a good idea (if 
> Implemented to avoid locking on repack -d)?

I'm mildly negative just because it increases complexity, and I don't think it's actually buying very much. It's not clear to me which invocations of repack would want to lock and which ones wouldn't.

Is "-a" or "-A" the key factor? Are there current callers who prefer the current behavior of "possibly duplicate some work, but never report failure" versus "do not duplicate work, but sometimes fail due to lock contention"?

-Peff