Git Svn dcommit error - restart the commit

Question

Last week, I made a number of changes to my local branch before leaving town for the weekend. This morning I wanted to dcommit all of those changes to the company's Svn repository, but I get a merge conflict in one file:

Merge conflict during commit: Your file or directory 'build.properties.sample' is probably out-of-date: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).

I'm not sure exactly why I'm getting this, but before attempting to dcommit, I did a git svn rebase. That "overwrote" my commits. To recover from that, I did a git reset --hard HEAD@{1}. Now my working copy seems to be where I expect it to be, but I have no idea how to get past the merge conflict; there's not actually any conflict to resolve that I can find.

Any thoughts would be appreciated.

EDIT: Just wanted to specify that I am working locally. I have a local branch for the trunk that references svn/trunk (the remote branch). All of my work was done on the local trunk:

$ git branch
  maint-1.0.x
  master
  * trunk
$ git branch -r
  svn/maintenance/my-project-1.0.0
  svn/trunk

Similarly, git log currently shows 10 commits on my local trunk since the last commit with a Svn ID.

Hopefully that answers a few questions.

Thanks again.

Answer 1

You should have created a local branch, and done the work on that, then when you get back, you update the master, rebase to the local branch, merge back to master then dcommit.

So I'd try copying out the changes, to back them up.

Create a local branch from the has svn sync point, merge your changes in there. Then back out the changes in the master branch, fetch, rebase to the branch, merge in from the local branch, fix any conflicts, then dcommit.

$ git checkout -b backup    # create a local backup branch with all your work
$ git checkout master   
$ git checkout -b backup2   # 2nd copy just to be safe
$ git checkout master
$ git reset --hard <this is the revision of the last svn-id> # clean up master to make the svn merge easier
$ git svn fetch    # this should update to the current version on the svn server
$ git rebase master backup  # may get a conflict here, fix and commit
... # after conflict is fixed and commited
$ git checkout master 
$ git merge backup --ff  # merge in your local commits
$ git svn dcommit        # push back to the svn

You can get additional info here

Another answer you might be interested in.

git-svn workflow articles

Simple

Another

Answer 2

To complete sfossen's excellent answer, here is some details:

With git-svn, you get by default a local branch named master. You should not do any work on it, only keep it up-to-date with the svn trunk branch with:

• git svn fetch to get the history from the svn trunk branch on your local trunk branch: it will not apply those modifications on your working directory
• git checkout master to switch on trunk branch (only if you were on another branch)
• git rebase trunk to synchronize master with trunk.

However, all your modifications should be done on another local branch (lets call it local-devel).

• git branch local-devel
• git checkout local-devel

If you have an urgent fix to do:

• git checkout master : swith on master(),
• git svn fetch && git rebase trunk to update it with svn trunk
• git branch fastfix && git checkout fastfix, branch it
• fix the bug, compile, test,
• git commit -a: local commit,
• git svn dcommit update the modification to the distant svn repo
• git checkout master && git rebase trunk: update master again
• git branch -D fastfix: remove hotfix branch
• git checkout local-devel && git rebase master: get back to dev, with the updated history done on master replayed on your dev branch

It is a bit of an hassle at first, but way more comfortable than an svn diff in a file to be applied later.

Answer 3

With much appreciation for VonC and sfassen's extraordinary patience with me, the solution sort of worked itself out. I don't know how or why, but maybe my initial rebase didn't work. To fix it I ended up rebasing again. From my local trunk branch:

$ git co -b backup  # backup the commits to my local trunk
$ git co trunk      # return to the local trunk
$ git svn rebase    # rebase the trunk from the Svn server
$ git br -d backup  # delete the backup branch

The key, of course, was that the rebase worked this time. I have no idea why it didn't work when I first did it, but I can't roll the clock back so I won't dwell on it.

Thanks again for everyone's suggestions and patience with a newbie.

Answer 4

I was going to comment, but thought this deserved more visibility...

git svn rebase is supposed to re-write your commits. From the description and comments, I get the impression that after you rebased, you forced your old commits back on top. The commits have to be replaced with newer versions that don't conflict.

To avoid having to dig through the reflog, you might want to get in the habit of making a quick tag before doing your git svn dcommit. After the dcommit succeeds, delete the tag. If the tag fails, you can do a git reset --hard followed by a git merge <tag>. Re-run your rebase to get your history back in order, re-tag and re-dcommit again.

Answer 5

I had a similar situation. I was doing an git svn dcommit over a bad network connection and it failed at some point. I've discovered that the problem was caused by the fact that Subversion repository already had a new commit, but local git-svn counterpart considered that a commit was not in SVN yet. Solutions from other answers here did not help, however this did:

git svn reset -r <last_svn_commit_git_was_aware_of>
git svn fetch
git svn rebase

After this I was finally able to do git svn dcommit without any errors.