Re: git-revert is a memory hog

On Mon, 28 Jan 2008, Jeff King wrote:

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 definitely can reproduce it, it's horrid.

This is from "top" fairly late in the game, but with the thing not even 
done yet. Current git, pretty much fully (and fairly aggressively) packed 
current kernel repo, and using "diff.renamelmit=0".

	4751 torvalds  20   0  852m 446m  47m R   72 22.4   2:46.58 git-merge-recur

It finally finished with time reporting:

	208.15user 3.50system 4:01.50elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k
	238736inputs+4544outputs (8261major+280971minor)pagefaults 0swaps

where those 280971 minor page faults are what largely indicates how much 
memory it used (the technical term for that number is "metric buttload of 
memory").

But I'm in Melbourne right now on my laptop,and probably won't be able to 
debug this much. 

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).

It is indeed git-merge-recursive. It just shouldn't take that much memory.

		Linus