Re: git-revert is a memory hog

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> Hrm, setting diff.renamelimit to 0 lets me reproduce (I thought I tried
>> it before, but clearly not...).
>
> Hmph.  But I wonder why this part does not trigger, even when
> you have renamelimit set to 0.
>
> 	/*
> 	 * This basically does a test for the rename matrix not
> 	 * growing larger than a "rename_limit" square matrix, ie:
> 	 *
> 	 *    rename_dst_nr * rename_src_nr > rename_limit * rename_limit
> 	 *
> 	 * but handles the potential overflow case specially (and we
> 	 * assume at least 32-bit integers)
> 	 */
> 	if (rename_limit <= 0 || rename_limit > 32767)
> 		rename_limit = 32767;
> 	if (rename_dst_nr > rename_limit && rename_src_nr > rename_limit)
> 		goto cleanup;
> 	if (rename_dst_nr * rename_src_nr > rename_limit * rename_limit)
> 		goto cleanup;
>
> I wonder if the second one for the overflow avoidance should be
> using || instead of &&, though.

Reverting d19fbe8a7 means coming up with a 3-way merge between
d19fbe8a7^ and master as if d19fbe8a7 is their common ancestor.

"git diff --name-status d19fbe8a7 d19fbe8a7^" shows only two
paths changed.

"git diff --name-status d19fbe8a7 master" shows 8558 new paths
and 3756 deleted paths, which makes 32m paths pairs, that is
still lower than 32767 squared.

If your int is 64-bit, struct diff_score which is 4-int is
16-byte long.  32m * 16 = 501,801,600.  That seems to match your
450MB observation well.