Adrian Bunk <bunk@xxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
