Re: git-revert is a memory hog
- From
Jeff King <peff@peff.net>
- Date
- Jan 28, 2008, 05:59 UTC
- Message-ID
- <20080128055933.GA13521@coredump.intra.peff.net>
- In-Reply-To
- <20080127172748.GD2558@does.not.exist>
On Sun, Jan 27, 2008 at 07:27:48PM +0200, Adrian Bunk wrote:
Show 14 quoted lines
> <-- snip --> > > $ git-revert d19fbe8a7 > Auto-merged drivers/input/input.c > CONFLICT (content): Merge conflict in drivers/input/input.c > Auto-merged include/linux/input.h > CONFLICT (content): Merge conflict in include/linux/input.h > Automatic revert failed. After resolving the conflicts, > mark the corrected paths with 'git add <paths>' and commit the result. > $ > > <-- snip --> > > In top you can see that this took > 800 MB of RAM !
I tried to reproduce this, but my peak heap allocation was only around 20MB. Is your repository fully packed? Not packed at all? Can you use valgrind/massif to figure out where the memory is going?
> 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
In your case, the patch doesn't apply cleanly, so we end up doing a 3-way merge (in my tests, it is git-merge-recursive which ends up taking up the memory).
-Peff