1

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?

Community
  • 1
  • 1
sdaau
  • 36,975
  • 46
  • 198
  • 278
  • Commits with different hashes are different commits. – jthill Mar 15 '15 at 14:01
  • if you're trying to list commits only to a certain point, then tell log where you want to stop. If there's anything there you don't expect, the grep will hide it. just do --all -50 or something to get the latest 50. – jthill Mar 15 '15 at 14:21
  • 1
    Go back and do it again in light of the above two, and pay attention to the branch structure the log shows you. – jthill Mar 15 '15 at 14:23
  • Thanks @jthill - you're right about the listing; but in this case this isn't the problem (I did check with full logs first, then re-checked with a grep to have a more compact code for posting here). For the hashes, git svn somehow integrates a `git-svn-id:` in the commit message, whereby hashes change; - and once `git svn dcommit` is done, then all commits should have a `git-svn-id:`, and the graph tree is not split anymore. – sdaau Mar 15 '15 at 16:41

1 Answers1

0

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...

Community
  • 1
  • 1
sdaau
  • 36,975
  • 46
  • 198
  • 278