Hello, I have troubles understanding the behaviour of `git apply` with respect to renames in a `--no-index` context. Let us craft a toy folder: ```sh $ mkdir x $ echo a > x/a # To be modified. $ echo b > x/b # To be renamed. ``` Duplicate it twice to get three identical folders `x = y = z`. ```sh $ cp -r x y $ cp -r x z ``` Modify `y`: ```sh $ echo newline >> y/a # Edit. $ mv y/b y/c # Rename. ``` Now I would like to use git as a "better GNU patch". Calculate the diff from `x` to `y`: ```sh $ git diff --no-prefix x y | tee patch diff --git x/a y/a index 7898192..4030aa5 100644 --- x/a +++ y/a @@ -1 +1,2 @@ a +newline diff --git x/b y/c similarity index 100% rename from x/b rename to y/c ``` Then apply this patch to `z` so as to end up with `x != y = z`: ```sh $ git apply -p1 --directory z patch error: z/x/b: No such file or directory ``` I would expect `z/b` to be renamed into `z/c`, but I get the above error instead. Although understand that `z/x/b` is not a valid path, I don't understand that git produces such a path, because I'm assuming that `-p1` is supposed to remove the `x/` part. Interestingly, the procedure works fine without the rename. The rename also worth fine if I manually remove the `x/` and `y/` prefixes from the rename lines in the patch. This makes the behaviour of `git apply` appear inconsistent. It is nonetheless expected ? If so, why ? If not, then is it a bug ? Thank you for support, [System Info] git version: git version 2.46.2 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh libcurl: 8.10.1 OpenSSL: OpenSSL 3.3.2 3 Sep 2024 zlib: 1.3.1 uname: Linux 6.10.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 12 Sep 2024 17:21:02 +0000 x86_64 compiler info: gnuc: 14.2 libc info: glibc: 2.40 $SHELL (typically, interactive shell): /usr/bin/zsh [Enabled Hooks] not run from a git repository - no hooks to show -- Iago-lito
