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!)

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?

  • How to finish this git rebase operation?
  • Can I find pre-rebase commits?
  • Delete some commits from remote repository assuming I'm the only person working on it
  • Subversion rebase?
  • Git - origin/master diverged - throwing away abandoned commit
  • What's the difference between 'git merge' and 'git rebase'?
  • the correct way of git rebase
  • Move a branch to a new tag
  • 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.