Iago-lito <iago-lito@xxxxxxx> writes: > Hello @Junio, and thank you for feedback :) > > If I understand correctly, you are suggesting that `git diff`/`git > apply` are behaving correctly here, but they might not be the right > tool for the job? No. "git diff --no-index" is giving "wrong" information in the rename/copy extended diff headers, but regular "git diff" is perfectly fine. Also "git apply" is perfectly fine. And the "wrong"-ness above is in the eyes of beholder, in the sense that the original folks who coaxed "these two directories are not controlled by Git, but unlike GNU diff, "git diff" has a few nice bells and whistles, so instead of adding these properly to GNU diff, abuse "git diff" to add a mode where two directories are compared" probably did not view that "git diff --no-index X Y" must be equivalent to committing the contents of X first and then Y next, and then doing "git show" on the resulting history. I do not know why being different and showing X and Y as part of the paths reported on the "rename from" etc. extended diff headers could sometimes be useful, but they must have had some use cases I am not seeing offhand. So in order to lift this "wrong"-ness, you'd probably want an option to the "no-index" mode of the "git diff" (in "diff-no-index.c") to omit the leading directory name (i.e. X/ and Y/) from these rename/copy extended diff headers. Then your toy example would work when the "git diff --no-index --fixed-rename-copy-path-info" is used.
