Re: git rev-list | git cherry-pick --stdin is leaky

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 30, 2013, 18:31 UTC
Message-ID: <7vsj27dg5d.fsf@alter.siamese.dyndns.org>
In-Reply-To: <517F0C18.8060703@codeaurora.org>

Stephen Boyd <sboyd@codeaurora.org> writes:

Show 8 quoted lines

> (resending since the attachment seems to make vger sad)
>
> Hi,
>
> I'm running git rev-list | git cherry-pick --stdin on a range of about
> 300 commits. Eventually the chery-pick dies with:
>
>     error: cannot fork() for commit: Cannot allocate memory

Unfortunately, I am not very surprised.

The merge-recursive machinery was designed in the "run once and let exit() clean up after ourselves" manner, which lets it not even having to worry about keeping track of what needs to be cleaned up. Reusing it inside cherry-pick and revert without updating it was OK, but extending cherry-pick and revert to take more than one change without addressing its resource management was a large mistake.

I vaguely recall suggesting to fork and perform a three-way merge in a separate process when operating on more than one commit when this feature was first discussed. We may have to do something like that.