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

testrepo.png

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 dcommits to myrepo_svn_WS.

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

So, myrepo_git_LS.git has the same commits as myrepo_git_wc, as expected – so far so good.

At first, myrepo_gitsvn shows this for the git log --graph ...

* 964b300 (HEAD, git-svn, master) : null edit - starter

So 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 myrepo_gitsvn:

$ git svn rebase
user@ssh.server'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 rebase to --continue in myrepo_gitsvn:

$ 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?

  • Split svn2git in multiple revisions
  • Source control when working on open source projects
  • Move/rename directory with git-svn
  • Are merges in subversion more difficult than in Team Foundation System?
  • svn ignore a file but include it in checkout
  • How do I Automate Keeping my TortoiseSVN Project Up-to-date?
  • maven scm plugin migration from SVN to GIT
  • svn path not found on branch not involved in merge operation
  • 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:

    • the | * would indicate a git-svn commit, that is one with a “SVN” SHA hash
    • the * on top indicate “plain git” commits, which only have a git SHA hash
    • and * | 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…

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