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< --
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
We might want to introduce a way to express the similarity score for
such a filepair that was manually constructed when showing the
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