Taylor Blau <me@xxxxxxxxxxxx> writes: > When cruft packs were implemented, we never adjusted the code for `git > gc`'s `--keep-largest-pack` and `gc.bigPackThreshold` to ignore cruft > packs. This option and configuration option share a common > implementation, but including cruft packs is wrong in both cases: > > - Running `git gc --keep-largest-pack` in a repository where the > largest pack is the cruft pack itself will make it impossible for > `git gc` to prune objects, since the cruft pack itself is kept. Makes sense. We want to keep the largest pack that is actually in use, and we want to consolidate other non-cruft packs into one. > - The same is true for `gc.bigPackThreshold`, if the size of the cruft > pack exceeds the limit set by the caller. This is not as cut-and-dried clear as the previous one. "This pack is so large that it is not worth rewriting it only to expunge a handful of objects that are no longer reachable from it" is the main motivation to use this configuration, but doesn't some part of the same reasoning apply equally to a large cruft pack? But let's assume that the configuration is totally irrelevant to cruft packs and read on. > --keep-largest-pack:: > - All packs except the largest pack and those marked with a > - `.keep` files are consolidated into a single pack. When this > - option is used, `gc.bigPackThreshold` is ignored. > + All packs except the largest pack, any packs marked with a > + `.keep` file, and any cruft pack(s) are consolidated into a > + single pack. When this option is used, `gc.bigPackThreshold` is > + ignored. "except the largest pack" -> "except the largest, non-cruft pack"
