Re: [PATCH 17/17] fetch: add fetch.writeCommitGraph config setting
- Date: Thu, 9 May 2019 10:21:23 -0400
- From: Derrick Stolee <stolee@xxxxxxxxx>
- Subject: Re: [PATCH 17/17] fetch: add fetch.writeCommitGraph config setting
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