Re: [PATCH] revert & cherry-pick: run git gc --auto

> 
> On Thu, Oct 11 2018, Phillip Wood wrote:
> 
> > Hi Ævar
> >
> > On 10/10/2018 20:35, Ævar Arnfjörð Bjarmason wrote:
> >> Expand on the work started in 095c741edd ("commit: run git gc --auto
> >> just before the post-commit hook", 2018-02-28) to run "gc --auto" in
> >> more commands where new objects can be created.
> >>
> >> The notably missing commands are now "rebase" and "stash". Both are
> >> being rewritten in C, so any use of "gc --auto" there can wait for
> >> that.
> >
> > If cherry-pick, revert or 'rebase -i' edit the commit message then they
> > fork 'git commit' so gc --auto will be run there anyway.
> 
> Yeah it seems I totally screwed up the testing for this patch, first it
> doesn't even compile because I'm not including run-command.h, I *did*
> fix that, but while wrangling a few things didn't commit that *sigh*.
> 
> And yeah, there's some invocations where we now run gc --auto twice,
> i.e. if you do revert, but not revert --no-edit, and not on cherry-pick,
> but on cherry-pick --edit.
> 
> So yeah, this really needs to be re-thought.
> 
> > I wonder if it would be better to call 'gc --auto' from sequencer.c at
> > the end of a string of successful picks, that would cover cherry-pick,
> > 'rebase -iu' and revert. With 'rebase -i' it might be nice to avoid
> > calling 'gc --auto' until the very end, rather than every time we stop
> > for an edit but that is probably more trouble than it is worth.
> 
> That seems a lot better indeed. I.e. running it from the sequencer. I do
> wonder if there should be some smarts about running it in the middle of
> a sequence, i.e. think of a case where we're rebasing 10k commits, which
> is a gc need similar to what happens in the middle of "git svn
> clone". So maybe something where we gc --auto in the sequencer for every
> Nth commit, and at the end.