On 5/9/2019 4:07 AM, Ævar Arnfjörð Bjarmason wrote: > > So rather than have this patch I'd like to as noted in 00/17 get the > refactoring bits of the commit-graph in first. Refactor-only series coming soon. > Then some version of my WIP patch in > https://public-inbox.org/git/87lfzprkfc.fsf@xxxxxxxxxxxxxxxxxxx/ where > we'd note the number of objects we had when we did the last commit-graph > in the graph itself. > > Then "gc --auto" would look at that, then approximate_object_count(), > and have some percentage threshhold for doing a "do some of the gc" > task, which would just be a small change to need_to_gc() to make it > return/populate a "what needs to be done" rather than "yes/no". > > That would give you what you want here, but also be a more general > solution. E.g. we'd write the graph on "clone" once "gc --auto" was > called there, as well as on "fetch". I think this "gc --auto" idea is solid, but I also think there is value in writing a commit-graph after _every_ fetch, not just one big enough to trigger this new gc behavior. Perhaps your new metadata in the commit-graph file could store multiple values for "number of objects since X was cleaned up" where X is in { packs, reflog, commit-graph, etc. } and GC could consider each maintenance task independently. _That_ would make this patch unnecessary. Thanks, -Stolee
