Git-Svn dcommit causes branch splitting

I’m having a problem with gitsvn dcommits making the git repository lose track of which commits are which.

I try to make sure that the master branch in git always follows trunk in the SVN repository. So whenever I’m working, I’m on a topic branch. Here’s my scenario:

  • Why Gerrit is accepting pushes, it can't handle?
  • broken bash prompt wrap line
  • How to set up Git as VCS on windows workstation/server for web projects(ASP)?
  • How do I save a `git reset`
  • How to check the differences between local and github before the pull
  • What's the real function for git-stash and git-rebase?
  • Working in a topic branch for a while

    git checkout -b my-topic
    git commit -m "blah blah blah"
    

    Then I decide I’d like to merge my branch back in to master

    git checkout master
    git svn rebase #get any changes in svn
    git rebase master my-topic
    git merge my-topic --ff-only
    

    Up until here, everything has gone well. I now have both master and my-topic up to speed and pointing at the same commit, and the entire history looks like this:

    A -- B -- C - master + my-topic
    

    However, when I do

    git svn dcommit
    

    I end up with a tree that looks like this (B and C are commits I originally made to the topic):

      -- B -- C - my-topic
     /
    A -- B -- C - master + remotes/trunk
    

    It seems like during the dcommit process, git pushes the commits up to SVN, then replays them back on top of master. The problem I think is that they get different committer information. I’m logging into svn with tortoise plink and an SSH key.

    Commits in the git repository that have not been pushed to SVN have committer info as:

    Collin Hockey <chockey@xyz.com>
    

    Commits that have been pushed to the svn repository have this though:

    chockey <chockey@6206317d-b652-48a9-a948-4036602fc523>
    

    Is there any way I can keep these branches from splitting? I can sort of fix it by saying

    git rebase master my-topic
    

    again, but I feel like that should be unnecessary. The main problem with this is that once a branch’s changes are pushed to SVN, git no longer thinks that branch has been merged anywhere. It makes it confusing to delete old branches you no longer need.

  • Git philosophy: how to get “master” branch to “production” branch?
  • Git warnings when certain files have changed
  • How to work on a drop-in library?
  • How to diff a file with specific revision in git?
  • Setting color-words option by default on git-show
  • How to rebase in IntelliJ IDEA
  • 2 Solutions collect form web for “Git-Svn dcommit causes branch splitting”

    The git svn dcommit command works as follows:

    1. Find the last commit coming from SVN; let’s call it last-svn
    2. Send the commits in the range last-svn..HEAD to Subversion (discarding the e-mail by the way)
    3. Reset the HEAD to last-svn
    4. Update from SVN and create the corresponding commits

    In other words, the commits you send to SVN are destroyed and recreated from the update from SVN. This must happen because the commits that come from SVN are different from the ones created with Git:

    • Their description contains a reference to the SVN revision
    • Their author e-mail is computed from the SVN username

    That’s why your branch my-topic diverges from master.

    You can customize the way git svn dcommit computes the author e-mail from the SVN username with the --authors-file and --authors-prog options.

    you are right, that git replays the commits again from svn. branches in git are only pointers to commits (or there ids/hashes). the commits from svn will have different hashes, and only the currently checked out branch is updated by git svn dcommit, so your topic branch still points to the old commits

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