Junio C Hamano <gitster@xxxxxxxxx> wrote: > Implement git gc --auto ... Danger... If the user sets `gc.auto` to a low enough value and they are also unlucky enough to have a few truely unreachable (thus pruneable) objects in .git/objects/17/ then this is going to run a bunch of gc work on every commit they make. I'm actually running into this problem in git-gui. On Windows it suggests a repack if there is one object in .git/objects/42/. Some users have been unlucky enough to stage a file, have it hash into that directory, then restage a different version of it. The prior one is never considered reachable (it was never committed), but will now *always* cause git-gui to suggest a repack on every startup. For all time. Yea, I need to fix that. But this suffers from the same fate if the user sets gc.auto too small and doesn't realize that the reason Git is always repacking is because over the last 6 months they have been unlucky enough to stage the magic number of unreachable blobs into the 17 directory and they have *never* run `git gc --prune` because the auto thing is working just fine for them and they don't realize they need to prune every once in a blue moon. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
