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

branchgitreintegrationsvn

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

I have a svn TRUNK that looks like this:

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?

Best Answer

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.

Related Solutions

Git – Undoing a git rebase

The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog...

git reflog

and to reset the current branch to it (with the usual caveats about being absolutely sure before reseting with the --hard option).

Suppose the old commit was HEAD@{2} in the ref log:

git reset --hard HEAD@{2}

In Windows, you may need to quote the reference:

git reset --hard "HEAD@{2}"

You can check the history of the candidate old head by just doing a git log HEAD@{2} (Windows: git log "HEAD@{2}").

If you've not disabled per branch reflogs you should be able to simply do git reflog branchname@{1} as a rebase detaches the branch head before reattaching to the final head. I would double check this, though as I haven't verified this recently.

Per default, all reflogs are activated for non-bare repositories:

[core]
    logAllRefUpdates = true

Git – the difference between ‘git pull’ and ‘git fetch’

In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).

A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

From the Git documentation for git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

Best Answer

Related Solutions

Git – Undoing a git rebase

Git – the difference between ‘git pull’ and ‘git fetch’

Related Topic