Re: [PATCH] array index mixup
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jul 16, 2006, 08:50 UTC
- Message-ID
- <7vejwmj5mv.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <E1G1jje-0007ey-OA@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> I dunno if this is really an index mixup or was intended. If this is > intended please add a comment what it's for. (Without this you get > rename information, perhaps this is the reason.)
That is exactly the reason -- it was a temporary workaround which nobody noticed so far.
The right fix would involve updating diff_resolve_rename_copy so that it does not rely on the comparison of path names (that means DIFF_PAIR_RENAME() macro needs to change), and instead mark the pairs synthesized in diffcore-rename as such, and use that to tell if a pair is a result of rename/copy [*1*].
Your other patch (not the one to change the index of the array used for labels, but the one that extracts the pathname out of the syntax to name a blob by path in an arbitrary tree object) could be safely applied when that happens.
[Footnote]
*1* If somebody wants to do this, one thing to watch out for is matching up of broken pairs. If a pair originally broken by diffcore-break (because they were dissimilar enough according to the option given to -B flag) are merged into one by diffcore-rename (because they were similar enough according to the option given to -M flag), we should _not_ say the resulting pair is renamed. In general, the threashold for breaking should be lower than diffcore-rename to merge them for a sane use, so this might be a non-issue in practice, though.