On Fri, 2016-12-16 at 16:32 -0500, Jeff King wrote: > On Fri, Dec 16, 2016 at 01:28:00PM -0800, Junio C Hamano wrote: > > > > 2. I don't understand what would cause that message. That is, what bad > > > thing am I doing that I should stop doing? I've briefly skimmed the > > > code and commit message, but the answer isn't leaping out at me. > > > > Enabling bitmap generation for incremental packing that does not > > cram everything into a single pack is triggering it, I would > > presume. Perhaps we should ignore -b option in most of the cases > > and enable it only for "repack -a -d -f" codepath? Or detect that > > we are being run from "gc --auto" and automatically disable -b? I > > have a feeling that an approach along that line is closer to the > > real solution than tweaking report_last_gc_error() and trying to > > deduce if we are making any progress. > > Ah, indeed. I was thinking in my other response that "git gc" would > always kick off an all-into-one repack. But "gc --auto" will not in > certain cases. And yes, in those cases you definitely would want > --no-write-bitmap-index. I think it would be reasonable for "git repack" > to disable bitmap-writing automatically when not doing an all-into-one > repack. I do not have alternates and am not using --local. Nor do I have .keep packs. I would assume, based on the documentation, that auto gc would be doing an all-into-one repack: "If the number of packs exceeds the value of gc.autopacklimit, then existing packs (except those marked with a .keep file) are consolidated into a single pack by using the -A option of git repack." I don't have any settings that limit the size of packs, either. And a manual git repack -a -d creates only a single pack. Its loneliness doesn't last long, because pretty soon a new pack is created by an incoming push. Unless this just means that some objects are being kept loose (perhaps because they are unreferenced)?