Using git-svn to merge a svn branch back into trunk and trunk back into the branch

So I’m using git and interacting with an svn repo.

I have a svn TRUNK that looks like this:

  • Routinely sync a branch to master using git rebase
  • How do I create a new branch using TortoiseSVN?
  • Git Mess! Commits in the wrong branch
  • Git- Tracking remote branches
  • How does one work on a new git branch that depends on another git branch that is not yet merged?
  • How should gitflow hotfixes work?
  • A-B-C-D
    

    And a svn bug_fixes branch that branches off at commit B or C:

     -c-d-e-f-g-h-i
    

    Now I need to get the cdefghi commits that are in my svn branch back into the master branch.

    I’m aware that I could just do a squashed commit, let’s call it squash SQUASH (which would contain cdefghi), but then it seems like I would have to kill the bug_fixes branch and start a new branch to cleanly continue.

    Here: http://blog.red-bean.com/sussman/?p=92 they suggest:

    checkout the branch.

    merge master’s changes into the branch.

    Checkout the master.

    merge --reintegrate the branch’s changes onto master.

    Continue development.

    Unfortunately, git-svn doesn’t seem to recognize any “merge –reintegrate” command for svn.

    So how do I cleanly make branch and master have all commits, so that development on both can continue, using git-svn’s commands?

  • Automate git bisect for MSBuild/NUnit/.NET/Windows batch commands in msysgit?
  • Protection against git removal of untracked .gitignored files?
  • Chef will not checkout development branch from git
  • Git - to fork or not to fork
  • `find -exec` in git alias
  • Git: Allow amending commits without erasing the history
  • 5 Solutions collect form web for “Using git-svn to merge a svn branch back into trunk and trunk back into the branch”

    The Caveats section of the git-svn documentation warns

    For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between git repositories and branches.

    The author does provide a recommendation:

    The recommended method of exchanging code between git branches and users is git format-patch and git am, or just dcommiting to the SVN repository.

    Adapting to your situation

    git format-patch --stdout c^..i >my.patch
    git reset --hard trunk
    git am <my.patch
    

    where c and i are appropriate identifiers for the commits in your history.

    Ok, so a few approaches that I found:

    git checkout your_branch
    git rebase master
    git checkout master
    git merge your_branch
    

    or

    git checkout your_branch
    git rebase master
    git checkout master
    git merge --squash your_branch
    

    or

    git checkout your_branch
    git rebase master
    git checkout master
    git rebase -i your_branch
    

    And then after all that.

    git svn dcommit (to commit to master)
    git branch -D your_branch
    

    Then (from svn because git-svn doesn’t support deletion) delete the branch,
    and recreate it from trunk and start the cycle all over again.

    Would this not be a good case for rebasing your local stuff (<branchpoint>..i) onto the new master fetched from SVN?

    If you dcommit a merge it automatically squashes it into 1 commit. Sadly it does not internally use svn:mergeinfo or –reintegrate as it should, so you lose the association with the branch created via ‘git svn branch’.

    What you also can do is cherry-pick, provided that you wouldn’t use merge.

    Both statements should be done on the branch without the changes.

    Provided that c is older than i and that you want to take the whole sequence.

    git cherry-pick c..i
    

    Or separate commits

    git cherry-pick c d e f g h i
    
    Git Baby is a git and github fan, let's start git clone.