Is git-svn dcommit after merging in git dangerous?


My motivation for trying out git-svn is the effortless merging and branching. Then I noticed that man git-svn(1) says:

Running git-merge or git-pull is NOT recommended on a branch you plan
to dcommit from. Subversion does not represent merges in any
reasonable or useful fashion; so users using Subversion cannot see any
merges you’ve made. Furthermore, if you merge or pull from a git
branch that is a mirror of an SVN branch, dcommit may commit to the
wrong branch.

Does this mean I cannot create a local branch from svn/trunk (or a branch), hack away, merge back into svn/trunk, then dcommit? I understand that svn users will see the same mess that merges in svn pre 1.5.x have always been, but are there any other drawbacks? That last sentence worries me, too. Do people routinely do these kinds of things?


Actually, I found an even better way with the --no-ff option on git merge.
All this squash technic I used before is no longer required.

My new workflow is now as follows:

  • I have a “master” branch that is the only branch that I dcommit from and that clone the SVN repository (-s assume you have a standard SVN layout in the repository trunk/, branches/, and tags/):
  • I work on a local branch “work” (-b creates the branch “work”)
  • commit locally into the “work” branch (-s to sign-off your commit message). In the sequel, I assume you made 3 local commits

    gt; git commit -s -m “msg 1”


    gt; git commit -s -m “msg 2”


    gt; git commit -s -m “msg 3”

Now you want to commit onto the SVN server

  • [Eventually] stash the modifications you don’t want to see committed on the SVN server (often you commented some code in the main file just because you want to accelerate the compilation and focus on a given feature)

    gt; git stash
  • rebase the master branch with the SVN repository (to update from the SVN server)

    gt; git checkout master

    gt; git svn rebase
  • go back to the work branch and rebase with master

    gt; git checkout work

    gt; git rebase master
  • Ensure everything is fine using, for instance:

    gt; git log –graph –oneline –decorate
  • Now it’s time to merge all three commits from the “work” branch into “master” using this wonderful --no-ff option

    gt; git checkout master

    gt; git merge –no-ff work
  • You can notice the status of the logs:

    gt; git log –graph –oneline –decorate
    * 56a779b (work, master) Merge branch ‘work’
    | * af6f7ae msg 3
    | * 8750643 msg 2
    | * 08464ae msg 1
    * 21e20fa (git-svn) last svn commit
  • Now you probably want to edit (amend) the last commit for your SVN dudes (otherwise they will only see a single commit with the message “Merge branch ‘work'”

    gt; git commit –amend
  • Finally commit on the SVN server

    gt; git svn dcommit
  • Go back to work and eventually recover your stashed files:

    gt; git checkout work

    gt; git stash pop

Leave a Reply