Re: `git apply -p` doesn't remove source prefix in 'rename' diff entries.

[Junio C Hamano <gitster@pobox.com>]

Iago-lito <iago-lito@cleb.io> 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.