I've no idea exactly how this came to pass but my git-svn is now fubar.
ERROR from SVN:
Transaction is out of date: File '/proj/some/file.java' is out of date
No changes between 61f2c8cfa5881aab335edc2c0807f288c420f624 and refs/remotes/svn/git-svn
Resetting to the latest refs/remotes/svn/git-svn
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.
There was a similar question on SO before, but neither solution worked for me - there are no merge conflicts, and moving aside .git/svn and running git svn fetch
did not change the error from git svn dcommit
. Running fetch did have one interesting statement:
M proj/some/file.java
... [merge list] ...
Last fetched revision of refs/remotes/svn/git-svn was r8104, but we are about to fetch: r8102!
Not sure what that means.
Edit: When I looked at the tree in SourceTree, I could see that the SVN was "ahead" of the master branch and that commits after r8102 were "duplicated" in both trees. Reverting the master to before r8102 and attempting to move forward again did not resolve the problem.
Edit 2: The tree looks something like this:
+-------D---E---F---G remote/svn/git-svn
/
A---B---C---D---E master
Before I attempt the suggested git rebase remotes/svn/git-svn master
by @Ben what should I expect? There are a lot of commits (B & C here) that aren't apparing in the remote, but are in the master, I noticed that the duplicates seem to be somehow related to my switching between different tunneling methods. I need to protect the svn here, this is more for my personal interest (and future avoidance of problems).
From my .subversion/config:
[tunnels]
wlan = /usr/bin/ssh -F /dev/null -l petri -t -A wifi-gateway /usr/bin/ssh -F /dev/null -l svnremote -A
wan = /usr/bin/ssh -F /dev/null -l petri -t -A extern-gateway /usr/bin/ssh -F /dev/null -l svnremote -A
This results in different svn commit comments like
git-svn-id: svn+wan://dev/svn/v9/trunk@8102 b9636cbc-3124-4d49-8704-a9669b6dc9bf
I'm wondering if there isn't some bad reference id problems here...