git svn rebase misses/loses commits (on rebase –continue due merge conflict)?
I have a problem with missing commits, in a setup very similar to the one described in Unexpected merge error in a git svn system? (click for full size):
- possible to recreate svn repository from (full) git-svn clone?
- Reintegrate a branch with externals fails in SVN
- Does Go development require a paid Github account for private development?
- How to split an SVN folder into its own repository when it has been renamed?
- Subversive Reject Credentials
- Converting a CM Synergy archive to free source control
Unfortunately, I cannot reproduce this problem in an example, so I’ll try to provide the information that I think is relevant. I work locally in
myrepo_git_wc and so it represents the “original source”; currently it has this state of the last few commits (all of which have “null edit” in the name, so I’m grepping after that):
$ git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order | grep 'null edit' * 03ed433 (HEAD, master) : damnit, null edit again * de3bd53 (origin/master, origin/HEAD) : previous null edit passed * 65bf738 : again null edit - no improvement * 62ab3f6 : still bad; trying again w null edit * 14f5aba : another null edit; previous was bad * f0ef194 : null edit - starter
I push my work here to
myrepo_git_LS.git bare repo; which then using a
post-update hook updates the
myrepo_gitsvn – which ultimately
So, at the moment,
myrepo_git_LS.git shows the following (with the same
git log --graph... command as above):
* 03ed433 (HEAD, master) : damnit, null edit again * de3bd53 : previous null edit passed * 65bf738 : again null edit - no improvement * 62ab3f6 : still bad; trying again w null edit * 14f5aba : another null edit; previous was bad * f0ef194 : null edit - starter
myrepo_git_LS.git has the same commits as
myrepo_git_wc, as expected – so far so good.
myrepo_gitsvn shows this for the
git log --graph ...
* 964b300 (HEAD, git-svn, master) : null edit - starter
myrepo_gitsvn is at the oldest “null edit” commit (although the hash is not the same); which is the same revision where the
myrepo_svn_WS is at. I’d like to add the new commits in
myrepo_gitsvn repo too — so, from
myrepo_gitsvn, I do:
git pull --rebase origingit master
… which should pull in the commits from
myrepo_git_LS.git. Now, the
myrepo_gitsvn shows this
git log --graph...:
* 03ed433 (HEAD, master) : damnit, null edit again * de3bd53 : previous null edit passed * 65bf738 : again null edit - no improvement * 62ab3f6 : still bad; trying again w null edit | * 964b300 (git-svn) : null edit - starter ... * | 14f5aba : another null edit; previous was bad * | f0ef194 : null edit - starter ...
It’s kinda weird that here I get the oldest “null edit – starter” commit twice; also the original commit SHAs are shown here. At this point, the graph tree is shown as split (i.e. git and SVN commits are shown separately).
So, I’m thinking, if I do here
git svn rebase (as I usually do in my workflow, with which I haven’t had problems previously) then the repo would be able to “compact” these commits. Unfortunately
--verbose doesn’t reveal here much detail, but this is the output when running this command in
$ git svn rebase firstname.lastname@example.org's password: First, rewinding head to replay your work on top of it... Applying: : still bad; trying again w null edit Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging folder/file.tex CONFLICT (content): Merge conflict in folder/file.tex Failed to merge in the changes. Patch failed at 0001 : still bad; trying again w null edit When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/git-svn: command returned error: 1
Since it says it failed at “still bad; trying again w null edit“, which is commit 62ab3f6 – I simply checkout that revision of the file (although the same happens if I edit the file manually in a text editor); and then ask
$ git checkout 62ab3f6 folder/file.tex $ git add folder/file.tex $ git rebase --continue Applying: : still bad; trying again w null edit Applying: : again null edit - no improvement Applying: : previous null edit passed Applying: : damnit, null edit again
It almost looks good; but if I do the
git log --graph ... command now in the
myrepo_gitsvn, I get:
* eef9e50 (HEAD, master) : damnit, null edit again * 9b2af2d : previous null edit passed * 380b0f9 : again null edit - no improvement * a41db2b : still bad; trying again w null edit * 964b300 (git-svn) : null edit - starter
If you compare with the original state — besides the commit SHA hashes not being the same, there is another problem: the commit “another null edit; previous was bad” (which should have been between “null edit – starter” and “still bad; trying again w null edit“) is not present anymore?!! Basically, I could
git svn dcommit this state now – and it would be uploaded to the SVN server without errors; but I’d lose one of the commits – which then will possibly cause problems during rebasing later!
Thus, at this point I delete the latest commits in
myrepo_gitsvn by resetting like this:
git reset --hard 964b300 git svn reset -r446 git svn rebase
… which brings about the state with which this post started (and so I can loop with this procedure indefinitely).
My question is – what can I do, so all of the commits present originally in the git side, are recognized and integrated by the svn side as well; or in other words, how can I force
git svn to also pick up this lost/missing commit?
One Solution collect form web for “git svn rebase misses/loses commits (on rebase –continue due merge conflict)?”
Just a few notes; seemingly, this has to do with the “null edit – starter” commit being present twice. The way I see it, in the split tree graph:
| *would indicate a
git-svncommit, that is one with a “SVN” SHA hash
*on top indicate “plain git” commits, which only have a git SHA hash
* |would indicate a commit with a git SHA hash – but one that apparently is already present in SVN too!
That means, that
* | 14f5aba : another null edit; previous was bad would mean that somehow, git-svn got the information that this was present in the SVN – and yet this was rev 447, “null edit – starter” was rev 446 – and the head of SVN was 446.
But – it was 446 because in previous attempts, I tried to Manually deleting only the latest revision from online SVN repository? – and apparently, there was a state where 447 was also in the SVN tree, and so git-svn somehow recorded that.
At this point, I tried to first Remove specific commit – the
14f5aba one, but that didn’t work; apparently this binding between git and SVN commits is recorded somewhere else. So what I did was to “fake” commit a revision 447 on SVN (as I already had the source git of the same revision, I could do the same patch, and the same commit message, resulting with the same git hash) – and that allowed that the commit was finally found on next rebase. But then I got in other trouble with the same repo … So, ultimately I’m not sure if this is all there is to it…