Nick Bowler <nbowler@xxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html