Re: git-revert is a memory hog

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 29, 2008, 22:53 UTC
Message-ID: <7v7ihsmeg7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vfxwgmf87.fsf@gitster.siamese.dyndns.org>

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

Show 26 quoted lines

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