Git fails to track changes after renaming files

[NoiseDoll]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.26.2.windows.1
cpu: x86_64
built from commit: 4267c88d0d8936ae723bba55e0576b1c4f3d4e1a
sizeof-long: 4
sizeof-size_t: 8

and

git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19041.388]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Default

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Tested on two different machines with different git version. Same result and the repro is not 100% you may need several attempts to reproduce bug.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

You need two files with content

$ cat "Lightning Booster (x1).asset.meta"
fileFormatVersion: 2
guid: 2f2681a5c7030a44995b40805d64d815
NativeFormatImporter:
  externalObjects: {}
  mainObjectFileID: 0
  userData: 
  assetBundleName: 
  assetBundleVariant: 

$ cat "Mixer Booster (x1).asset.meta"
fileFormatVersion: 2
guid: 43cbec228323ae247b0c2aa626c52a3e
NativeFormatImporter:
  externalObjects: {}
  mainObjectFileID: 0
  userData:
  assetBundleName:
  assetBundleVariant:

Then you need to rename them both in this order

$ mv "Lightning Booster (x1).asset.meta" "Shuffle Booster (x1).asset.meta"
$ mv "Mixer Booster (x1).asset.meta" "Lightning Booster (x1).asset.meta"

• What did you expect to occur after running these commands?

I expect to see this

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   Lightning Booster (x1).asset.meta
        deleted:    Mixer Booster (x1).asset.meta

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        Shuffle Booster (x1).asset.meta

no changes added to commit (use "git add" and/or "git commit -a")

$ git diff "Lightning Booster (x1).asset.meta"
diff --git a/Lightning Booster (x1).asset.meta b/Lightning Booster (x1).asset.meta
index ccca0d8..e701fb0 100644
--- a/Lightning Booster (x1).asset.meta
+++ b/Lightning Booster (x1).asset.meta
@@ -1,5 +1,5 @@
 fileFormatVersion: 2
-guid: 2f2681a5c7030a44995b40805d64d815
+guid: 43cbec228323ae247b0c2aa626c52a3e
 NativeFormatImporter:
   externalObjects: {}
   mainObjectFileID: 0

• What actually happened instead?

With some chance it results in git doesn't see changes in file Lightning and assumes that it's a Mixer is renamed into Shuffle

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    Mixer Booster (x1).asset.meta

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        Shuffle Booster (x1).asset.meta

no changes added to commit (use "git add" and/or "git commit -a")

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

Repro repository with is attached
SampleRepo.zip

[rimrul]

That sounds like git working as expected.

The old and new Lightning files have identical content and the same name. That's an unchanged file as far as git is concerned.

The contents of the old Mixer file and the new Shuffle file are also identical, that gets detected as a rename.

The only way to work around this in such a situation where similar files get renamed and some of the old names get reused is to split the renames over multiple commits.

[rotanov]

The old and new Lightning files have identical content and the same name. That's an unchanged file as far as git is concerned.

That's not quite right. Before execution of

$ mv "Lightning Booster (x1).asset.meta" "Shuffle Booster (x1).asset.meta"
$ mv "Mixer Booster (x1).asset.meta" "Lightning Booster (x1).asset.meta"

Lightning and Mixer were different. And since Mixer got renamed to Lightning it means "new" Lightning is different from "old" one. If you simply resave Lightning git will start to display it as modified. But resave didn't change the content.

The contents of the old Mixer file and the new Shuffle file are also identical, that gets detected as a rename.

This is also wrong because of what stated above.

lets say we have A and B, where A != B. If you rename A => C, B => A', then A != A' and B != C

[rimrul]

I might be missing something, but the contents posted above seem identical to me. I haven't looked at the attached repo yet, though. Anyways, if they're different git should detect that as a modification, unless maybe an identical mtime is tricking git.

[NoiseDoll]

oh, sorry, wrong content pasted... I'll update post

[rotanov]

They're different in the attached repo. Might be a mistake in post.

[dscho]

Can the MCVE be turned into a minimal set of shell commands, without using funny characters (like spaces and parentheses) in the file names, and with contents generated via seq <start> <end>?

[evanunderscore]

I also ran into this bug and submitted #3441 before I found this issue. I've managed to reproduce it with a single move on trivial text files.

[rotanov]

@evanunderscore that's great, because over a year I wanted to make a repro like @dscho asked but never had the chance every time when I remembered about this issue.

[dscho]

Can the MCVE be turned into a minimal set of shell commands, without using funny characters (like spaces and parentheses) in the file names, and with contents generated via seq <start> <end>?

This still holds true. Please provide a really simple, small shell script (or if you must, Powershell or Batch script) that reproduces the issue.

[evanunderscore]

@dscho I believe I provided this in #3441, sorry for splitting the information across two issues. Copying the important details over:

# Setup
git init mvtest
cd mvtest
echo a > a.txt
echo b > b.txt
git add .
git commit -m 'add files'

# Commands to trigger the bug (may need to paste as a block multiple times to trigger the bug)
git status
mv b.txt a.txt
git status
git checkout .
cat a.txt
cat b.txt

Sometimes the modification to a.txt is not detected; git checkout . does not reset the contents of a.txt, and git status shows no changes.

$ git status
On branch master
nothing to commit, working tree clean

$ mv b.txt a.txt

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    b.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git checkout .
Updated 1 path from the index

$ cat a.txt
b

$ cat b.txt
b

Once you are in this broken state, you can touch a.txt to have the change actually be detected.

$ touch a.txt

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   a.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git checkout .
Updated 1 path from the index

$ cat a.txt
a

This reproduces for me in Git Bash or with equivalent commands in cmd.exe. However it does not reproduce totally reliably, which seems to imply some kind of race condition.

[dscho]

However it does not reproduce totally reliably, which seems to imply some kind of race condition.

This makes me wonder whether it has anything to do with FSCache, i.e. whether the problem still occurs after git config core.FSCache false. (The issue reporting template called for the contents of /etc/install-options.txt, which would have given me a clue whether FSCache was turned on, but now I don't.)