Re: git-revert is a memory hog

["Shawn O. Pearce" <spearce@spearce.org>]

Adrian Bunk <bunk@kernel.org> wrote:
> I'm not sure whether this is already known, but when recently working 
> for some time from a computer with "only" 512 MB RAM I ran into the huge 
> memory usage of git-revert when it tries to revert old commits.
> 
> Example (in Linus' kernel tree with git 1.5.3.8):
> 
> $ git-revert d19fbe8a7
...
> In top you can see that this took > 800 MB of RAM !
> 
> I don't know how easy it would be to implement, but shouldn't git-revert 
> be able to be as fast and less memory consuming as
>   git-show d19fbe8a7 | patch -p1 -R

Its more like:

	git-diff-tree -M d19fbe8a7^ d19fbe8a7 | git-apply -R --index

In other words its doing rename detection.  Its possible that the
rename detector fired for added/removed paths and it took some
significant amount of memory to figure out what was renamed.
Maybe we hung onto stuff for too long, but it has to do rename
detection and that takes memory to store the matrix and file
contents.  Once memory is allocated by git we don't give it back
to the kernel, even if we free'd it internally.

If you really are tight on memory and have to do a revert you can
use the above, but minus the -M, to setup the change, but you may
run into trouble if renames were involved.

-- 
Shawn.