Nguyen Thai Ngoc Duy <pclo...@gmail.com> writes: > The above output is done with "git diff --manual-rename=foo A B" > and "foo" contains (probably not in the best format though) > > -- 8< -- > attr.c dir.c > dir.c attr.c > -- 8< -- > ... > Comments?
It is a good direction to go in, I would think, to give users a way to explicitly tell that "in comparison between these two trees, I know path B in the postimage corresponds to path A in the preimage". I however wonder why you did this as a separate function that only does the explicitly marked ones. Probably it was easier as a POC to do it this way, and that is fine. The real version should do this in the same diffcore_rename() function, by excluding the paths that the user explicitly told you about from the the automatic matching logic, and instead matching them up manually; then you can let the remainder of the paths be paired by the existing code. Notice how the non-nullness of rename_dst[i].pair is used as a cue to skip the similarity computation in the expensive matrix part of diffcore_rename()? That comes from find_exact_renames() that is called earlier in the function. I would imagine that your logic would fit _before_ we call find_exact_renames() as a call to a new helper function (e.g. "record_explicit_renames()" perhaps). Anything that reduces the cost in the matrix part should come earlier, as that reduces the number of pairs we would need to try matching up. We might want to introduce a way to express the similarity score for such a filepair that was manually constructed when showing the result, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
