Reverting a swath of commits consumes all memory and dies.

[Nick Bowler <nbowler@elliptictech.com>]

Hi folks,

I just noticed that git-revert when given a large batch of commits will
consume more and more memory as commits are reverted.  Eventually, git's
usage exceeds about half of the available memory and dies because fork
fails with -ENOMEM.  This appears to be gratuitous, because after git
dies you can simply run

  git reset --hard
  git revert --continue

and the revert will pick up right where it left off.  Reverting commits
one at a time also works.  I can reproduce it (for example) with the
following example, using current master git:

  % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  % cd linux
  % git revert --no-merges --no-edit HEAD~50..

watch git's memory usage increase indefinitely with "top", until...

  error: cannot fork() for commit: Cannot allocate memory
  fatal: revert failed

  % git reset --hard
  % git revert --no-edit --continue

repeat as needed until eventually there's few enough commits left that
the revert completes without running out of memory (or git-revert fails
for some other reason).

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)