> -----Original Message----- > From: Jeff King [mailto:p...@peff.net] > Sent: Tuesday, April 18, 2017 1:20 PM > To: David Turner <david.tur...@twosigma.com> > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com > Subject: Re: [PATCH] repack: respect gc.pid lock > > On Tue, Apr 18, 2017 at 05:16:52PM +0000, David Turner wrote: > > > > -----Original Message----- > > > From: Jeff King [mailto:p...@peff.net] > > > Sent: Monday, April 17, 2017 11:42 PM > > > To: David Turner <david.tur...@twosigma.com> > > > Cc: git@vger.kernel.org; christian.cou...@gmail.com; > > > mf...@codeaurora.org; jacob.kel...@gmail.com > > > Subject: Re: [PATCH] repack: respect gc.pid lock > > > > > > On Mon, Apr 17, 2017 at 11:29:18PM +0000, David Turner wrote: > > > > > > > We saw this failure in the logs multiple times (with three > > > > different shas, while a gc was running): > > > > April 12, 2017 06:45 -> ERROR -> 'git -c repack.writeBitmaps=true > > > > repack -A -d > > > --pack-kept-objects' in [repo] failed: > > > > fatal: packfile ./objects/pack/pack-[sha].pack cannot be accessed > > > > Possibly some other repack was also running at the time as well. > > > > > > > > My colleague also saw it while manually doing gc (again while > > > > repacks were likely to be running): > > > > > > This is sort of a side question, but...why are you running other > > > repacks alongside git-gc? It seems like you ought to be doing one or the > other. > > > > But actually, it would be kind of nice if git would help protect us from > > doing > this? > > 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. So given that the lock will catch the races, might it be a good idea (if Implemented to avoid locking on repack -d)?
