Cherry-pick and stash don't work with an error: add_cacheinfo failed to refresh for path '...'; merge aborting.

[dropsonic]

• 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.22.0.windows.1
cpu: x86_64
built from commit: d003d728ffa6c0006da875ec6318d3f6b28a4ddb
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.18362.900]

• 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: Notepad++
Custom Editor Path: 
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
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?

4 worktrees

Details

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

cmd/PowerShell

• 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 cherry-pick [commitid]
# OR
git stash pop

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

Successful cherry-pick or merging the stash with the current branch

• What actually happened instead?

An error:
error: add_cacheinfo failed to refresh for path 'WebSites/Pure/ContractBasedApiTests/test_soap.sh'; merge aborting.
The stash entry is kept in case you need it again.

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

Unfortunately, it is a private repository that cannot be shared.

There are multiple complains about this issue on the Internet:
https://stackoverflow.com/questions/48080112/git-error-addinfo-cache-failed-for-path-file
https://stackoverflow.com/questions/16112561/error-addinfo-cache-failed-while-cherrypicking
https://www.reddit.com/r/git/comments/e606ld/why_does_this_file_prevents_me_from_merging_my/

Any solution that will help to return the repo into the working state would be much appreciated.

[PhilipOakley]

Can you try with the latest version to see if it is fixed. Those links are to old reports.

This link https://stackoverflow.com/a/57199694/717355 suggests it's a End of Line (EOL) normalisation issue. Have a search of the manuals for 'normalize' and 'eol' for clues on fixing the repo on the particular machine, particularly --renormalize.

If you can report back if the latest Git & the --renormalise works for you that would be great.

[PhilipOakley]

Also, if you manage to create a reproduction method for the fault, an MVCE, that would greatly help in sorting out any fixes either in upstream Git, or in Git-for-Windows (if it's special to Windows).

Thanks

[dropsonic]

@PhilipOakley thanks for your advice.
I've checked on the latest version, and it is still reproducible.

git version 2.28.0.windows.1
cpu: x86_64
built from commit: 77982caf269b7ee713a76da2bcf260c34d3bf7a7
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh

Also, I've tried to re-commit the changes using git add -A --normalize and cherry-pick the resulting but that didn't help.

As for the MVCE, I'd be happy to provide one but I don't know how. We have quite a large repo that is several years old, and it is under NDA so I'm not eligible to share it.

Can I provide anything else, maybe some additional logs, for example? .gitconfig or .gitaatributes content, maybe?

[tboegi]

@dropsonic
If we suspect that this is caused by an "EOL issue", you do some debugging:
In the commit, where you want to start the cherry-pick (master ??):
Run the command
git ls-files --eol

Then checkout the commit, which you want to cherry-pick.
Run
git ls-files --eol
as well.
Please post the 2 results here.
Could that work ?

[dropsonic]

@tboegi each result contains more than 20k lines. Do you want me to post the whole set?

[tboegi]

@dropsonic :
If we suspect an issue with EOL,
we need to look for lines starting with "i/crlf".
From my knowledge, we can rule-out EOL issues, if there are no lines
starting with "i/crlf".
Feel free to zip those 2 files and send them to my email, if you want help this way.

[dropsonic]

@tboegi unfortunately, I can't send the list of files in the repository because of legal restrictions from my employer.
I checked, and I see a mix of i/lf, i/-text, i/crlf, i/mixed, i/none in both files.

.gitattributes:

* text=crlf

.gitconfig:

[core]
	autocrlf = false

[tboegi]

The .gitattributes file looks wrong to me.
The i/-text indicates that there are binary files ?
Please have a look at the documentation here about binary and text files:
https://git-scm.com/docs/gitattributes

To be able to find out if the EOLs are the reason for the
"add_cacheinfo failed" problem. you can try to do the following:
Look at the commit that you want to cherry-pick:
Does it include file additions ?
Are files "renamed", moved between directories ?
Or is it a pure change of tracked files ?
In this case, try to split the commit into single commits for each file-
This is for testing only, use a clone of the repo if needed.
Then please post the ls-files information for that file, that fails here.

[dropsonic]

@tboegi so it should be * text eol=crlf, right?

I checked the commit I was trying to cherry-pick. It was a pure change of a single tracked file. This file is marked as i/crlf both in the source and in the target branch.

[tboegi]

@dropsonic
Thanks for digging.
That makes me wonder:
With all information, that you have (and we don't):
Can you create a demo repo, that makes the problem reproducible for others?

[dropsonic]

@tboegi unfortunately, I can't reproduce it in any other repo (probably because they are way more consistent and much younger). Maybe I can enable some advanced logs in Git and collect them?

[tboegi]

My idea was to create an unconsistent repo on purpose.
(And I am afraid that we don't have any logging, that can be enabled in Git).
Stepping through a debugger can work (on your existing repo)
Adding logging to Git can work (and, again, run Git on your local repo).
You need to compile Git yourself for that.

Or somebody else has a public repo, where the code execution in Git can be studied ?

[dropsonic]

It's a pity that Git doesn't have any logging that can be enabled to diagnose such issues. Are there any plans to add it?
Unfortunately, I don't know any public repo where this issue exists.
Thank you for your help anyway. I'll try to do some investigation locally.

[PhilipOakley]

Does the git fast-export --anonymize (and re-import) provide a repo that still shows the problem?

It may be a route to creating a minimal example, see https://git-scm.com/docs/git-fast-export/2.28.0#_anonymizing

[dropsonic]

@PhilipOakley thanks for the idea, I was not aware of that option. Will try it and let you know the results.

[rbagali]

I have the same issue but with the "git pull origin " as well as "git merge" commands. Is there any resolution for this? in my case i see that a file was renamed.

[dscho]

in my case i see that a file was renamed.

@rbagali unfortunately, this is a far distance from a proper Minimal, Complete & Verifiable Example..

Please have a closer look in particular to what git ls-files --eol <file> has to say, and then do your best to reproduce this issue in a short list of commands within a fresh repository (i.e. start by git init reproduce-2781 and cd reproduce-2781, then try to recreate the problem e.g. by creating and committing a file with the end-of-line characteristics matching the original scenario).

[ChristianStadelmann]

See also: #1780

[dscho]

Since there is no MCVE to work with, and since there has been ample time to provide one, I'll close this ticket.