On Tue, Apr 18, 2017 at 05:16:52PM +0000, David Turner wrote: > > -----Original Message----- > > From: Jeff King [mailto:peff@xxxxxxxx] > > Sent: Monday, April 17, 2017 11:42 PM > > To: David Turner <David.Turner@xxxxxxxxxxxx> > > Cc: git@xxxxxxxxxxxxxxx; christian.couder@xxxxxxxxx; mfick@xxxxxxxxxxxxxx; > > jacob.keller@xxxxxxxxx > > 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? -Peff