Re: Unexpected behavior in git diff --relative=<path>

> Le 5 janv. 2026 à 17:56, Harrison McCullough <mccullough.harrison@gmail.com> a écrit :
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
> - Create a "foo.txt" file
> - Commit the "foo.txt"
> - Modify the "foo.txt" file
> - Create a "foo/bar.txt" file
> - Commit the "foo/bar.txt"
> - Modify the "foo/bar.txt" file
> - Run `git diff --name-only --relative=foo`
> 
> 
> What did you expect to happen? (Expected behavior)
> 
> I would expect to only see modified files inside the "foo/" directory. For
> example, I would expect this to be the output:
> 
> ```
> $ git diff --name-only --relative=foo
> bar.txt
> ```
> 
> 
> What happened instead? (Actual behavior)
> 
> Both the "foo/bar.txt" _and_ the "foo.txt" files were listed--but the "foo.txt"
> file had the "foo" prefix stripped, appearing as just ".txt".
> 
> ```
> $ git diff --name-only --relative=foo
> .txt
> bar.txt
> ```

> What's different between what you expected and what actually happened?
> 
> Using the `--relative=<path>` flag to `git diff` appears to simply remove the
> prefix from each file, regardless of whether that is a full path prefix or just
> part of the file name.
> 
> 
> Anything else you want to add:
> 
> This is the relevant part of the man page for `git-diff`:
> 
>> When run from a subdirectory of the project, it can be told to exclude changes
>> outside the directory and show pathnames relative to it with this option. When
>> you are not in a subdirectory (e.g. in a bare repository), you can name which
>> subdirectory to make the output relative to by giving a <path> as an argument.
>> --no-relative can be used to countermand both diff.relative config option and
>> previous --relative.