On Sun, Jan 27, 2008 at 07:27:48PM +0200, Adrian Bunk wrote: > <-- 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 - 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
