Stephen Boyd <sb...@codeaurora.org> writes:
> (resending since the attachment seems to make vger sad)
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html