git - error: addinfo_cache failed for path 'file'

Question

When I try to merge any branch in git into master I get error: addinfo_cache failed for path 'file'.

What I do:

>git checkout master
>git merge other-branch

Git gives me:

error: addinfo_cache failed for path 'file'
file: unmerged (581c47f7d0e1a0bc825d528d9783ac18ee0cce27)
file: unmerged (26a0c24dccd2bc2f74e20488ca01bba2fcd9cf56)
file: unmerged (3be471ca5c689693339827a455f187814677642f)
fatal: git write-tree failed to write a tree

>git status yields:

On branch master
Your branch is up-to-date with 'origin/master'.
Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add <file>..." to mark resolution)

        both modified:   file

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

I have no idea what to do and can't find anython on the problem.

Answer 1

This error can occur when you have changed the core.autocrlf config option but have not deleted and re-checked-out your working tree.

So either change core.autocrlf back to what it was, or push up your changes, delete your repo and clone it again.

Answer 2

The solution for me was very simple. After:

$ git pull
error: add_cacheinfo failed to refresh for path 'file'; merge aborting.

I performed the following simple operation:

$ rm file  # delete the failed file, or rename it if you want to keep it
$ git checkout file  # git recreates the file
$ git pull
From [server].com:[org]/[repo]
 * branch                [branch] -> FETCH_HEAD
Merge made by the 'recursive' strategy.
# success!

Answer 3

I tried editing the above answer but it does not seem to have progressed... After looking at your comment https://stackoverflow.com/users/6950750/derweh, deleting a repo is the absolute last resort. When quirky things seem to happen such as above. I found the best thing to do is reset to a past commit that has some considerable amount of delta and then checking back out the branch you need.

git reset HEAD~10 --hard or git checkout some-other-branch

followed by

git checkout name-of-your-branch

After doing this, your working branch often appears to work again.

Answer 4

I've recently encountered this error using 2.18.0.windows.1 git version when cherry-picking. The affected file wasn't even connected with the changes. Tried all the answers in this thread, tried disabling fscache and upgrading git to 2.21. Finally managed to resolve the issue by:

1. Removing the affected file
2. Resetting the state with git reset --hard origin/master (this did not work without step 1)

Answer 5

1. Did you try to first solve the conflicts you have on the "file" by running git mergetool, and afterwards merging your "other branch" into master?
2. Or if you don't care about you local changes to this "file" then you could just reset it hard to the remote branch git reset --hard origin/master and afterwards do the git merge other-branch

Answer 6

It's definetly somthing with the autocrlf like others allready said. But i have had it disabled ever since.

Sometime it's sufficient if a coworker or any tool like a mergetool or repo-frontend like gitlab, tfs, github fiddles with the line endings in a file, for example in pull requests.

easy local fix: - delete all code files - let git regenerate all files as it thinks is correct

So keep your workspace/repository with the .git folder, BUT delete all other files.

example (all code is in src)

rm -rf ./src
git reset --hard .

Answer 7

Another workaround I found is to manually checkout and add the files to the branch before merging. If I am in a feature branch and want to merge master into that branch, the merge aborts with the error

error: add_cacheinfo failed to refresh for path 'a/b/c'; merge aborting.

To fix this, first clean the leftovers of the aborted merge from the working directory with

git stash && git clean -fd

Then, checkout the offending file(s) and commit them to the target branch before the merge:

git checkout master — a/b/c
git add a/b/c
git commit -m “Add file that prevents merging”

Afterwards, the merge should work (you might have to repeat the previous step if another file triggers the same error):

git merge master

Answer 8

When I had this error I simply moved the affected folders into another directory outside the repository, performed the merge, pushed the changes, moved the affected folders back, commited this and pushed it again.

Since two folders were affected, I had to move them one by one, as git didn't inform me about the second one on the first try.

It's not a nice solution, but it worked without reset or any other changes on the repository or git (I'm using git-extensions).

Answer 9

I faced this same issue during a merge with "git version 2.23.0.windows.1".
Running the same merge command under Cygwin using "git version 2.17.0" worked.

None of the above recommendations helped me (not even doing a new clone of the repo).

Answer 10

Had the same problem with Git version : git version 2.28.0.windows.1

Merging a branch give error error: add_cacheinfo on random files.

The solution I found was to remove my .gitattributes -> commit -> push -> re-merge.

Answer 11

I encountered this error when I used a custom merge driver. I basically set up the merge driver as the manual says:

in .git/config,

[merge "foo"]
    name = foo merge driver
    driver = foo.py %O %A %B %L %P
    recursive = binary

and in .git/info/attributes,

*.txt merge=foo

As the doc says,

The merge driver is expected to leave the result of the merge in the file named with %A by overwriting it,

and also

The merge driver can learn the pathname in which the merged result will be stored via placeholder %P.

I thought it would be okay if the result was written into %P, and so in foo.py I wrote:

with open(sys.argv[5], 'w') as f:
    f.write(some_str)

sys.argv[5] is %P. As a result, the error occurred. The file content was indeed merged as expected, but the file was neither staged nor committed. The process was interrupted by the error.

Then I modified foo.py:

with open(sys.argv[2], 'w') as f:
    f.write(some_str)

sys.argv[2] is %A. This way, the error was gone and the merge was successful as expected.

Answer 12

git merge <some_branch>

I figure this might be where the issue is faced (when merging the other branch).

I was able to solve the issue by following the below steps:

1. git merge <some_branch> Here you will see error
2. git status should give you the changes that were to be merged.
3. git commit . and git push to push the changes.
4. Now you can do git merge <some_branch>, delete/stash whichever files are suggested before merging. You wont find the error now.
5. Commit and push the changes.

Answer 13

I got this error when trying to merge a remote branch into my local repository. When I pulled down the remote and re-tried the merge, it worked fine.

It was likely also related to core.autocrlf, which I have changed recently, but I was able to merge locally.

Answer 14

I read a ton of answers, tried many. What fixed it for me - and it's a very humbling experience - was computer 101 -

I restarted the machine.

The setup is linux machine on cloud, distributed file system - that usually worked perfectly over hundreds of days without a restart.

I really wish there would be a more specific error and analysis on this one..

Answer 15

This happened to me when I updated git & tortoise git. Given that I restarted my work on a old repo I am unable to pin-point what git version I had initially and what update/change exactly triggered the issue.

I was trying to avoid all the (hard)reset / rebase answers.

What helped me (on Win10) was the following.

1. Copy local repo 'X' into your drive. I do not understand what happens during the copy from git / tortoise perspective but when clicked Git Show Log on my 'X - copy' it has shown many files modified (probably CRLF issue, previous merge was fine without any problems/complaints from git)

2. Commit (I also pushed but it does not matter because it is your local one which 'corrupted')

3. Now git commands execute properly on the 'X - copy'. I had to pull other branch in to merge.

So copying the local 'X' repo triggered the git (I assume the new timestamp triggers the git to check the file) to see the issue with the local 'X - copy' repo and a commit solved it. This commit however is a 'dummy' one.