Re: git-revert is a memory hog

On Tue, 29 Jan 2008, Junio C Hamano wrote:

No, we want to be able to handle the case where there is (for example) just one removed file, but lots of new ones. That's not expensive at all. So we don't want to require that *both* the counts for removed and new files are low, we really want to check that we don't have too many combinations together.

But  the

        if (rename_limit <= 0 || rename_limit > 32767)
                rename_limit = 32767;

which is there purely to avoid overflow in 32-bit multiplication should probably be changed to be more reasonable. We'll never want to try to do a matrix that is really 32k * 32k in size, even if we can calculate its size ;)

So maybe we should just make that hard limit more reasonable. 100x100 was too small, but a 1000x1000 matrix might be acceptable.

Or, better yet (which was what I was hoping for originally), we'd just make the inexact rename detection be linear-size/time rather than O(m*n). But those patches never really came together, so we do need to limit it more aggressively.

		Linus