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

From: Derrick Stolee <stolee@gmail.com>
Date: May 9, 2019, 14:21 UTC
Message-ID: <b1de6af2-c015-098e-a656-e1b68056e037@gmail.com>
In-Reply-To: <87imukgier.fsf@evledraar.gmail.com>

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.

Show 13 quoted lines

> Then some version of my WIP patch in
> https://public-inbox.org/git/87lfzprkfc.fsf@evledraar.gmail.com/ 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