Matthias Lederhofer <matled@xxxxxxx> 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. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html