Reverting a swath of commits consumes all memory and dies.
- From
- Nick Bowler <nbowler@elliptictech.com>
- Date
- Apr 24, 2012, 16:14 UTC
- Message-ID
- <20120424161403.GA24738@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/)