2

My project structure looks like this:

Parent repository (PR)
   - Child submodule 1 (S1)
   - Child submodule 2 (S2)
   - Child submodule 3 (S3)

When I want to rebase my parent repository it shows the following message:

Could not apply 53e9728... update submodules
Fast-forwarding submodule S1
Auto-merging S1
error: add_cacheinfo failed to refresh for path 'path/to/submodule'; merge aborting.

The problem only occurs when I try to rebase it. If I merge the branch to other branch it works fine!

I tried to use the solution here (changed core.autocrlf to false) and here (removed my branch and then pulled again from origin), but none of the solution fixed my issue. Is there any other way to fix the problem?

Edit: the problem occurs with one specific commit. I tried to cherry-pick that particular commit and the same error message showed up.

Edit 2: I ended up removing the commit from history. For me it was an option, but for others it may not be.

For future reference:

git rebase -i <commit id of the previous commit that needs to be deleted>

drop commit
SZT
  • 1,771
  • 4
  • 26
  • 53
  • The `core.autocrlf` setting should not really affect this. It's not clear to me why rebase is showing this problem, which isn't something ordinary users should ever see in the first place. – torek May 27 '21 at 07:00
  • @torek: this is first time I have experienced this problem. I took the suggestion from one of the suggestions I added above. What puzzles me even more that it behaves differently for rebase and merge – SZT May 27 '21 at 07:22
  • Re the edit: that part makes sense. There is something about that particular commit that gets Git bollixed up internally. What it is, is not clear; with a reproducer, it can probably be debugged and fixed. (The "aborting" should not happen; at worst, you should get a complaint that requires some sort of manual resolution, like a standard merge conflict.) – torek May 28 '21 at 05:42
  • @torek I ended up removing the commit from history. For me it was an option, but for others it may not be. – SZT May 30 '21 at 08:06

1 Answers1

0

I got this message for a submodule with a new commit inside of the submodule. Simply committing the new hash of the submodule on the parent repository fixed it for me.

Christian
  • 13,285
  • 2
  • 32
  • 49