Re: Reverting a swath of commits consumes all memory and dies.

Nick Bowler [off-list ref] writes:

I just noticed that git-revert when given a large batch of commits will
consume more and more memory as commits are reverted.

[Cc: people who have been involved in builtin/revert.c and sequencer.c]

Unfortunate, but not surprised.

Unlike other sequencing operations like 'rebase' and 'am', multi-commit
cherry-pick/revert were implemented in such a way that it calls into the
infrastructure functions that was meant to be used in "get invoked as a
single command, do that one thing well, and let exit(2) take care of
cleaning up the resources" repeatedly from within a single process.
Probably the series that implemented multi-commit cherry-pick/revert
should have first updated the infrastructure to reduce leaks, but
probably it looked shinier to add features than doing the necessary
legwork ;-)

Perhaps you (or anybody for that matter) can help by running them under
valgrind, which would be a good first step to find and fix the leaks.

Thanks.