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?
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:
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
git cherry-pick 67fceed5a80ff78ac6f9a437620323131c88cd51
(notice, it is the hash displayed in the error message!)
Resolve the conflicts (if any)
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
Rebase all commits reachable from
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