BUG: refs/files-backend.c:465: returning non-zero -1, should have set myerr!

[hoffmale]

• 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.35.1.windows.1
cpu: x86_64
built from commit: 8084c8c201ddb28eaff22bdd9c8344339eddab73
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• 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.19044.1466]

• 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

Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: CmdTools
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

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

This initially occured during pull request builds on our CI.

Details

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

CMD
I have not been able to reproduce this bug in git-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.

git init
git fetch --tags --force --progress -- https://github.com/hoffmale/containers.git +refs/heads/*:refs/remotes/origin/*
git checkout origin/master
git status

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

I expect git status to report no changes and exit successfully.

• What actually happened instead?

git status prints the following message BUG: refs/files-backend.c:465: returning non-zero -1, should have set myerr! and aborts (albeit with exit code 0).

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

I just tested it with this repository: https://github.com/hoffmale/containers.git
It doesn't seem to work with a freshly created one: https://github.com/hoffmale/example.git
This problem is not present in version 2.34.1

[dscho]

git init
git fetch --tags --force --progress -- https://github.com/hoffmale/containers.git +refs/heads/:refs/remotes/origin/
git checkout origin/master
git status

I can reproduce the problem and am investigating.

[dscho]

Hrm. It does not reproduce with a freshly-built git.exe. Curious.

[siprbaum]

I have added quite some details tohttps://github.com//issues/3655, containing more information, as it was talking about the same error. If I have a detached HEAD and a remotes ref pointing to the same commit, then I see the problem.
But best to look at the details provided in #3655.

[dscho]

@siprbaum thank you for providing info, but I think the problem lies with FSCache (i.e. completely elsewhere). At least I can reproduce the problem when running with a freshly-built git.exe while passing -c core.fscache=true.

[dscho]

Fix "BUG: refs/files-backend.c:465: returning non-zero -1, should have set myerr!" #3678

This fixes it for me locally. I started the workflow to build the installer and the portable Git. Once it finishes, these two artifacts will be available for downloading, and at that stage I will ask you gentle people to verify that this fixes your problem, so that we can get the release process for Git for Windows v2.35.1(2) going.

[dscho]

I started the workflow to build the installer and the portable Git. Once it finishes, these two artifacts will be available for downloading, and at that stage I will ask you gentle people to verify that this fixes your problem, so that we can get the release process for Git for Windows v2.35.1(2) going.

Here they are: the installer and Portable Git.

@hoffmale @siprbaum @luminans @benwitman could you please all verify that this fixes the bug for you?

[siprbaum]

@dscho Just to confirm,git -c core.fscache=false status works here (problem is gone).

I also tested the portable variant and can confirm that the problem is fixed!
Thank you for the quick fix!

[dscho]

Thank you @siprbaum! And here are the artifacts for the release I am going to start now: https://dev.azure.com/git-for-windows/git/_build/results?buildId=93847&view=artifacts&pathAsName=false&type=publishedArtifacts

[mavaddat]

I was also having this issue and git -c core.fscache=false status seems to have worked for me using the previous latest version (2.35.1.windows.1). I just downloaded and installed the pre-release and it seems to have fixed the issue for me too.

[dscho]

I just downloaded and installed the pre-release and it seems to have fixed the issue for me too.

Great, thanks! You can also upgrade to the latest release, which has the fix: https://github.com/git-for-windows/git/releases/tag/v2.35.1.windows.2

[benwitman]

I downloaded version linked and my git status is working now, albeit it also logs the following:

error: invalid object 100644 c04866e2358d6256566b6fc68318eeca5ecb34f0 for '.azuredevops/branches/official/bbdaemon/defaultMergeRules.yml'

[benwitman]

@dscho where can I get the vfs version of git with this fix?

[benwitman]

@dscho where can I get the vfs version of git with this fix?

nevermind, found it: https://github.com/microsoft/git/releases/tag/v2.35.1.vfs.0.0