Bryan Turner <btur...@atlassian.com> writes: > For us, the biggest issue was "git gc"'s insistence on trying to run > "git reflog expire". That triggers locking behaviors that resulted in > very frequent GC failures--and the only reflogs Bitbucket Server (by > default) creates are all configured to never ex[ire or be pruned, so > the effort is all wasted anyway.
Detecting that the expiry threshold is set to "never" before spending cycles and seeks to sift between old and new and not spawning the expire command? This seems like an obvious low-hanging fruit to me. > Another issue with the canned steps for "git gc" is that it means it > can't be used to do specific types of cleanup on a different schedule > from others. For example, we use "git pack-refs" directly to > frequently pack the refs in our repositories, separate from "git > repack" + "git prune" for repacking objects. That allows us to keep > our refs packed better without incurring the full overhead of > constantly building new packs. I am not sure if the above is an example of things that are good. We keep individual "pack-refs" and "rev-list | pack-objects" available exactly to give finer grained control to repository owners, and "gc" is meant to be one-size-fits-all easy to run by end users. Adding options to "git gc --no-reflog --pack-refs" to complicate it sounds somewhat backwards.
