Re: git-revert is a memory hog

Junio C Hamano [off-list ref] writes:

This instead allocates and keeps only M records in core.  For
each dst, we compute similarlity with all sources (so the number
of similarity estimate computations we do is still N x M), but
we keep the best src for each dst.  This is essentially to save
memory drastically by giving up to come up with better pairing.

I guess we could keep a handful best candidates per dst, instead
of just one, to further improve on this approach, and such a
change should be fairly straightforward.

An obvious side note to this patch is that if we are going to
limit us to only 1 source candidate per destination, we do not
even have to allocate.  We can just do similarity one-by-one for
each destination, and pair up with the best source as we go.

I did not code it that way, primarily because that would
permanently close the door to extend it back to keep multiple
candidates per dst, so that later ones that gets processed can
notice what happened to earlier ones.