git diff issue with renamed file

[Mirek Prudky]

Thank you for filling out a Git bug report!

Please answer the following questions to help us understand your issue.

 

What did you do before the bug happened? (Steps to reproduce your issue):

 

I have modified, deleted and renamed some files and wanted to get list of changes using

git diff --name-status --cached -- *.{c,h}

 

$ git status

On branch test

Changes to be committed:

  (use "git restore --staged <file>..." to unstage)

        deleted:    application/application/app_hw.c

        deleted:    application/application/debug.c

        modified:   application/application/init.c

        modified:   application/application/main.c

        new file:   application/application/nejaky1.c

        new file:   application/application/novy.c

        renamed:    application/application/stm32l0xx_hal_msp.c -> renamed_file.c

 

 

What did you expect to happen? (Expected behavior):

 

Result of $ git diff --name-status --cached -- *.{c,h}

expected to contain the same list of changes as obtained by git status

 

 

What happened instead? (Actual behavior):

 

git diff --name-status --cached -- *.{c,h} provides only the renamed file

in the list of changes.

 

$ git diff --name-status --cached -- *.{c,h}

A       renamed_file.c

 

 

 

 

What's different between what you expected and what actually happened?:

 

Based on the documentation, it is expected that $ git diff --name-status --cached -- *.{c,h}

will return list of all staged changes, however when at least one “rename” is staged, all

other changes are ignored by diff.

 

Without rename, git diff --name-status --cached -- *.{c,h} works as expected:

giving list of all the changes.

 

 

 

Anything else you want to add:

 

Please review the rest of the bug report below.

You can delete any lines you don't wish to share.

 

 

[System Info]

git version:

git version 2.29.1.windows.1

cpu: x86_64

built from commit: e6d53c456169235fe72602e2b4d985934fa9ad23

sizeof-long: 4

sizeof-size_t: 8

shell-path: /bin/sh

uname: Windows 10.0 19042

compiler info: gnuc: 10.2

libc info: no libc information available

$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe

 

 

[Enabled Hooks]

pre-commit

commit-msg

 

 

Miroslav Prudky

 

[Bryan Turner]

On Tue, Jul 13, 2021 at 4:58 AM Mirek Prudky <mirosla...@gmail.com> wrote:
>
> Thank you for filling out a Git bug report!
>
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue):
>
> I have modified, deleted and renamed some files and wanted to get list of changes using
>
> git diff --name-status --cached -- *.{c,h}
>
> $ git status
> On branch test
> Changes to be committed:
> (use "git restore --staged <file>..." to unstage)
> deleted: application/application/app_hw.c
> deleted: application/application/debug.c
> modified: application/application/init.c
> modified: application/application/main.c
> new file: application/application/nejaky1.c
> new file: application/application/novy.c
> renamed: application/application/stm32l0xx_hal_msp.c -> renamed_file.c
>
> What did you expect to happen? (Expected behavior):
>
> Result of $ git diff --name-status --cached -- *.{c,h}
> expected to contain the same list of changes as obtained by git status
>
> What happened instead? (Actual behavior):
>
> git diff --name-status --cached -- *.{c,h} provides only the renamed file

"git status" enables rename detection by default, but unless you've
modified your config "git diff" doesn't. If you update your "git diff"
command to be "git diff -M --name-status --cached -- *.{c,h}" does
that show what you expect to see? -M enables rename detection (or you
could use -C for copy detection, which includes rename detection). You
could also run "git config diff.renames true" or "git config
diff.renames copies" (potentially with --global if you want this on
every repository instead of just one) to make rename (or copy)
detection enabled by default.

>
> in the list of changes.
>
> $ git diff --name-status --cached -- *.{c,h}
> A renamed_file.c
>
> What's different between what you expected and what actually happened?:
>
> Based on the documentation, it is expected that $ git diff --name-status --cached -- *.{c,h}
> will return list of all staged changes, however when at least one “rename” is staged, all
> other changes are ignored by diff.
>
> Without rename, git diff --name-status --cached -- *.{c,h} works as expected:
> giving list of all the changes.
>

> Miroslav Prudky
>

[Mirek Prudky]

Thanks for response.

Using -M or -C is of no help.

Actually the original problem is not about not seeing the renamed file in the results of diff. Problem is that once at least one renamed file is present in the list of changes, diff shows only the rename and not the other files:

Result of diff, when at least one renamed file is staged:

Result of diff, when no renamed file is staged:

Dne úterý 13. července 2021 v 13:58:03 UTC+2 uživatel Mirek Prudky napsal:

[Bryan Turner]

On Tue, Jul 13, 2021 at 11:47 PM Mirek Prudky <mirosla...@gmail.com> wrote:

Thanks for response.

Using -M or -C is of no help.

Actually the original problem is not about not seeing the renamed file in the results of diff. Problem is that once at least one renamed file is present in the list of changes, diff shows only the rename and not the other files:

Result of diff, when at least one renamed file is staged:

Result of diff, when no renamed file is staged:

Thanks for that. I wonder if this might be related to path globbing. You're using Git Bash, right? So the "*.{c,h}" might be being expanded by bash. That means since you have a file in the current directory ("moved_file.c"), you end up with effectively "git diff --name-status --cached -- moved_file.c". At that point you're effectively filtering down to just that specific file. Without that file present, I'd guess that bash either passes the glob to "git diff" as-is or it expands to nothing and you end up with "git diff --name-status --cached --" without any filter paths--either of which would work.

So what happens if you run "git diff --name-status --cached -- \*.{c,h}" instead? At that point I'd expect you to need -M for it to detect the rename.

--
You received this message because you are subscribed to the Google Groups "git-for-windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to git-for-windo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/git-for-windows/e52e7f3e-f015-45e6-af6d-37c87f75ebe6n%40googlegroups.com.

[Mirek Prudky]

Thanks a lot.

Escaping the path globbing saved the day.

Excellent support. Thanks.

Dne středa 14. července 2021 v 9:00:18 UTC+2 uživatel btu...@atlassian.com napsal: