git rebase fails with Unknown exit code (128) from command: git-merge-recursive

Consider the following scenario:
– upstream repository with 2500 is stored in SVN
git user A imports the repository into git and commits 1 patch
– git user B imports the repository into git and commits 1 patch
– git user A wants to merge the patch from git user B

In this case, if user A uses git merge, then the git history will be polluted with the common svn commits (i.e. instead of 2502 commits, history will contain 2501+2501 = 5002 commits!)

  • Git produces “BUG: There are unmerged index entries”
  • How to ignore to level directory in Git but not other directories starting with same name?
  • What does the git option remote.unfuddle.push do?
  • Ignored files show up in changes not staged for commit
  • How to tag a git revision and then listing tagged revisions
  • How to login Gerrit as Administrator
  • If user A uses git rebase, then git history will be correct (2502 commits). This works fine in this simple scenario, but if user A and user B had not 1 but 1000 commits each then a strange complication arises: git rebase -Xours fails with the following message:

    First, rewinding head to replay your work on top of it...
    fatal: Could not parse object '98d7cd83de321e737b22240752cd178622d29406^'
    Unknown exit code (128) from command: git-merge-recursive 98d7cd83de321e737b22240752cd178622d29406^ -- HEAD 98d7cd83de321e737b22240752cd178622d29406
    

    You can e.g. reproduce this issue using the following github repositories:

    git clone https://github.com/opentk/opentk
    cd opentk
    git remote add mono https://github.com/mono/opentk
    git fetch mono
    git checkout -b integrate
    git rebase -Xours mono/rodo-consolidate-opentk
    

    Does anyone know why this happens? Any ideas how to resolve this issue?

  • Best practices to write .gitignore in this particular situation
  • Why does Git ignore the .vs directory?
  • Permission denied (publickey) on capifony deployment from windows with remote host gitlab
  • I want git to give me a list of files within a folder unedited since a given revision
  • Emacs: why shell-command “git log” works, but “git shortlog” doesn't?
  • User who made Pull Request doesn't appear in Contributor List after merge
  • 4 Solutions collect form web for “git rebase fails with Unknown exit code (128) from command: git-merge-recursive”

    I had a similar issue with this error and I gave up rebase, and instead used cherry-pick to pick the changes, and it worked fine.

    seems this is an issue that rarely needs to be explored. I just stumbled in this problem, and as suggested in this email, the problem really seems to be because you are trying to use a recursive strategy to a commit without parents (the master branch of another repository, for example).

    In my scenario I was joining two git repositories, rebasing the master of one in the master of the other. In your case, converting and merging svn repos, so I guess this is pretty much the same scenario.

    In my scenario, again, I was using strategy=recursive and strategy-option=renormalize, to ignore annoying line endings conflicts. It worked very good, although at a given time I had to issue an additional commit in the middle of the history just for the sake of discarding the line endings from committed files (which keeps as ‘modified’ until you commit them).

    Here is my approach to overcome the issue:

    1. git rebase <branch> --strategy=recursive --strategy-option=ours
    First, rewinding head to replay your work on top of it...
    fatal: Could not parse object '67fceed5a80ff78ac6f9a437620323131c88cd51^'
    Unknown exit code (128) from command: git-merge-recursive 67fceed5a80ff78ac6f9a437620323131c88cd51^ -- HEAD 67fceed5a80ff78ac6f9a437620323131c88cd51
    1. git cherry-pick 67fceed5a80ff78ac6f9a437620323131c88cd51
      (notice, it is the hash displayed in the error message!)

    2. Resolve the conflicts (if any)

    3. git rebase --continue

    From the second commit onwards, the recursive strategy will work as they all have parent (the one you just cherry-picked).

    You will have a few conflicts and some needed commits to normalize codes once in a while, but you will no longer be pestered by a lot of useless line ending conflicts that just serve to confuse and make bugs in the merged code.

    I consider this a bug as the recursive strategy might just assume if no parent, an ’empty’ commit/working tree should be used as base for the comparisons (so everything in the commit are actual additions and no modifications).

    One of the possible solutions is to use git gc --aggressive to remove all the links to the old commits. It helped for me.

    This is pretty old by now, but the option OP was looking for was --root.

    --root

    Rebase all commits reachable from <branch>, instead
    of limiting them with an <upstream>. This allows you to rebase
    the root commit(s) on a branch. […]

    As mentioned in another answer, the real problem here is git is expecting to find a parent commit where one doesn’t exist. Specifically, that happens while git is looking for the merge base between these two branches. --root tells git not to do that.

    Credit to jthill and his answer https://stackoverflow.com/a/23312760

    Git Baby is a git and github fan, let's start git clone.