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 rm - fatal: pathspec did not match any files
  • GIT picking up whitespace changes it shouldn't
  • Dockerhub automated builds with multiple private repos
  • Can “git fetch” be told not to use “git upload-pack” for local repositories?
  • What is the opposite of `git diff HEAD^`?
  • Is there a right way to combine two commits that are not in order?
  • 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?

  • Programmatically printing git revision and checking for uncommitted changes
  • How do I produce every possible git-status?
  • Git - Move the contents of a file into another directory
  • Add *, but sibling is being ignored
  • Display current GIT branch in visual studio?
  • Git diff - how to quit the diff listing
  • 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.