git commit marks all files in my repo for deletion! (Git 2.24.1.2)

[davidgreen99]

After upgrading Git for Windows to version 2.24.1.2, when I try to commit changes to one file, every file in my repo is marked for deletion. This obviously not good. Same effect reproduced by other members of my team.

Setup

• Git for Windows 64-bit

$ git --version --build-options
git version 2.24.1.windows.2
cpu: x86_64
built from commit: 992f0773022527b1b0cb1e0c13aec97dd5248053
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.14393]

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

Editor Option: Notepad++
Custom Editor Path: 
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Interactive Add: Disabled

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

n/a

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.

1. created a branch under Master in my repo, check it out locally.
2. add one file to my repo
3. git add .
4. git commit -m "message"

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

git status shows the new file staged

• What actually happened instead?

All existing files in repo listed for deletion
1 new file not staged

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

no, sorry

[rimrul]

I can't reproduce this. git commit still commits files as intended.

What did you expect to occur after running these commands?

git status shows the new file staged

That sounds wrong. A git status right after a git commit should not show staged files. The previously staged files where committed and should now be unchanged (and as such, not listed by git status). Just to be clear, did you run git add . in the root directory or some sub directory? And does git status actually say "deleted:" in front of the other files or are they just listed in red under "untracked files"?

[dscho]

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

no, sorry

This limits rather drastically what anybody else can do to help you.

Could you please verify that the same problem occurs in a freshly git init-ed worktree, after an initial commit that adds some (possibly empty) test file?

In other words: please do spend some time to provide a Minimal, Complete & Verifiable Example (what you provided as an MCVE starts by creating a branch in your repo, which is clearly neither minimal, nor verifiable in others' setups).

[mkleehammer]

I had the exact same problem and it is also a private repo I cannot share.

I can confirm that cloning the repo again "fixed it". The .git/config files are the same except the failing repo has hideDotFiles = dotGitOnly.

[core]
	repositoryformatversion = 0
	filemode = false
	bare = false
	logallrefupdates = true
	symlinks = false
	ignorecase = true
	hideDotFiles = dotGitOnly

The problem is very repeatable and is definitely the commit command. I modified a single line and staged it and the status command showed exactly what one would expect. Then, running just git commit on the command line marked all files as deleted. To eliminate the editor, I reset everything and tried git commit -m "testing" and the same thing happened.

Perhaps it is related to caching on Windows? I've saved the old repo and can perform some tests if it would help. Any suggestions?

[dscho]

Any suggestions?

Yes. Reduce your private repository that you cannot share into a very small, verifiable example that works elsewhere and that you can share.

Like, if you suspect that hideDotFiles = dotGitOnly is the problem, you could try to recreate it in a fresh worktree that you initialize via git init fresh-worktree.

It would be very unreasonable for me to even try to reproduce this problem here; For what I know, this problem is probably system-specific and I never encountered this myself, so all my time trying to come up with a reproducer would most likely be wasted.

[mkleehammer]

My company (and I would guess most) are not going to allow private repos to be shared. They contain a massive amount of history and there is no good way to reduce them to something useful, and even if there was I'd never get approval. This issue is important to the maintainers of Git for Windows, but my IT, security, and legal depts aren't going to see it is a priority.

That's why I saved it and offered to run some tests locally. As an open source maintainer also, I get where you are coming from, but there isn't a better way unless someone with a public repo also reports the problem.

I've confirmed that if I simply zip up the repo and unzip it elsewhere, the new copy does not exhibit the same problems. So even sharing the entire repo as-is wouldn't do any good, but just testing that is a new clue.

[dscho]

My company (and I would guess most) are not going to allow private repos to be shared.

I never asked you to do that. Read again what I wrote. I asked you to build up a minimal example, based on the shape of your private repository. Because you're the only one who can do that. Trying to guess what you could try to figure out the problem is most likely to cost an insane amount of time and lead nowhere.

I've confirmed that if I simply zip up the repo and unzip it elsewhere, the new copy does not exhibit the same problems

So this is interesting. By "zip up the repo" do you refer to the .git directory, or are you really using zip.exe to build an archive of all the worktree files and the .git directory?

It might make more sense to "tar it up" using tar pczf /path/to/archive.tar.gz . (note the p option which tries to preserve as much of the stat data as possible, including the modified time and permissions).

[PhilipOakley]

@mkleehammer can I suggest that if you have a look at git fast-export --anonymize and see if the anonymised version of the repo still exhibits the issue, then you may have a way of creating a (possibly large) MVCE that is at least sharable.

It might not, but at least gives you some options for some testing.

Hope that helps.