git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 24, 2012, 20:02 UTC
Message-ID
<xmqqk414gaof.fsf@junio.mtv.corp.google.com>
In-Reply-To
<20120424161403.GA24738@elliptictech.com>
Nick Bowler <nbowler@elliptictech.com> 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.
Previous: Nick Bowler
Message 2 of 2 in “Reverting a swath of commits consumes all memory and dies.”
  1. Nick BowlerApr 24, 2012
  2. Junio C HamanoApr 24, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.