Re: [PATCH 17/17] fetch: add fetch.writeCommitGraph config setting

[Derrick Stolee <stolee@xxxxxxxxx>]

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