15

I'm getting this error doing a git pull:

fatal: cannot rebase with locally recorded submodule modifications

Googling for this error message essentially no results! That was a first for me.

You can see this error in the git source control here (to verify it is a real error), https://github.com/git/git/blob/master/builtin/pull.c#L961

I tried deleting all the submodules in the project, re-init'ing them, etc and nothing will let me do a git pull on the master branch.

Aidan
  • 4,150
  • 2
  • 20
  • 16

2 Answers2

28

Obviously you've set your git pull to run git rebase. When you do this and have enabled submodule recursion, git pull checks to see if there are submodule changes within in range of commits that will be rebased, and refuses to run if so.

You can simply break this up into separate git fetch, git rebase and git submodule update commands. Rebase has no submodule recursion option and hence is not concerned here. Or, you could run git pull --no-recurse-submodules to tell git pull not to look at any submodules.

I tried deleting all the submodules in the project ...

You would have to delete the submodules from every commit in the range of commits to be rebased, which would replace all those commits with new ones that have no submodules. Since you're likely to replace them all with the rebase anyway, that's not that terrible, but it's also not very nice to yourself—it will make you have to go restore them to every commit in the rebased results.

x-yuri
  • 16,722
  • 15
  • 114
  • 161
torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    Shouldn't `git pull` refuse to rebase only if both my local commits and the new rebase point *both* have changed the submodule? I have a situation in which I'm updating some files outside the submodule and just because someone updated the submodule on the main branch I get these fatal errors which are extremely misleading. – Spidey Jul 22 '20 at 14:57
  • It probably should. There is ongoing work on making submodules work better, so if it isn't already fixed (I suspect it isn't but have not checked) you could do some work on this, or see if someone in the community wants to work on it. – torek Jul 22 '20 at 15:06
  • When you hit a commit that is skipped, take a look at this post: https://stackoverflow.com/questions/61905448/git-cherry-pick-and-then-rebase – StarShine May 11 '22 at 16:07
  • @StarShine: the submodule issue is not tied to the skipped-commit patch-ID issue (though there are some cross effects here). – torek May 11 '22 at 16:44
  • @torek ok, I'm not totally in the loop to be honest. I just had a rebase that failed due to submodules and then got hit by a skipped commit. I suspect more people will eventually loop through these posts to navigate the errors :) – StarShine May 12 '22 at 06:50
1

According to a somewhat complicated email, the problem is not due to a real issue with your repo or worktree, but stems from a limitation of git that will go away at some point in the future.

In most (all?) cases, the following should resolve the problem:

git pull --rebase --no-recurse-submodules
git submodule update --recursive

As soon as the rebasing and the submodule-updating are kept apart, git can cope with them alright.

If you have performed local changes to any of your submodules, be sure to push those first -- possibly going through the same routine as above for each submodule where pushing cannot succeed directly because other changes from remote need to be incorporated first.

Lutz Prechelt
  • 36,608
  • 11
  • 63
  • 88