Re: [PATCH 4/6] copy vs rename detection: avoid unnecessary O(n*m) loops

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2007, 23:27 UTC
Message-ID: <7vy7dpv4ls.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.0.999.0710261600510.30120@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 12 quoted lines

> The nice thing about the whole counting thing is that we really don't even 
> care. What happens is:
>
>  - *if* any rename at all happens, the rename detection will increment the 
>    "rename_used" thing even more for the source (once for each rename)
>
>  - so if the rename_used started out non-zero, it will never become zero 
>    in diff_resolve_rename_copy(), and every single detected "rename" will 
>    be considered a copy - exactly like we want.
>
>  - in other words, a "rename_used++" before rename-detection guarantees 
>    that you never see a rename, only a copy of the source.

Ok, and that is because we _know_ a broken pair means that the path itself remains in the postimage and any other postimage that takes from its preimage can never "rename the path away". They can only be copies. Which makes sense.

Show 7 quoted lines

> The above is actually true *even*if* the 
>
> 	if (!strcmp(p->one->path, p->two->path))
>
> code in diff_resolve_rename_copy() actually triggers,...
> ..., so not doing 
> the decrement there is equivalent to doing another pre-increment.

Yes, this is what confused me. So for a broken pair, the actual value of rename_used does not really matter. We only care about it not going down to zero.