Re: git-revert is a memory hog
- From
Shawn O. Pearce <spearce@spearce.org>
- Date
- Jan 27, 2008, 17:38 UTC
- Message-ID
- <20080127173808.GX24004@spearce.org>
- In-Reply-To
- <20080127172748.GD2558@does.not.exist>
Adrian Bunk <bunk@kernel.org> wrote:
Show 7 quoted lines
> 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
...
Show 5 quoted lines
> 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.