12

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?

Kzqai
  • 22,588
  • 25
  • 105
  • 137
  • so basically, none of the solutions do an exact reintegration, all leaving the branch in conflict if you keep using it? – Quartz Aug 01 '13 at 16:23
  • Frankly, looking back at this, i would do one of these two things: 1. Use a git repo without svn. 2. Use a central svn repo, and do all my merging and rebasing in git, without using the less capable svn branches at all. If I had to share any branches, I'd do so in a git mirror -without- a master branch and keep only the master branch in svn. But overall I'd dispense with svn if possible. – Kzqai Aug 01 '13 at 20:30

5 Answers5

7

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.

hdl
  • 1,028
  • 1
  • 9
  • 23
Greg Bacon
  • 134,834
  • 32
  • 188
  • 245
  • This allows me to apply all the commits to the trunk, but doesn't allow me to continue developing on the branch. Unfortunately, since svn has a linear revision history it seems that the recommended course of action is actually to merge the branch in to trunk, then delete the branch and create one of the same name. – Kzqai Feb 01 '10 at 00:06
3

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.

Kzqai
  • 22,588
  • 25
  • 105
  • 137
  • how to get branch from svn? it's stored in there.. not in local repo. – holms Feb 20 '13 at 15:05
  • I think it's just a matter of "Git svn fetch" or something. http://www.kernel.org/pub/software/scm/git/docs/git-svn.html – Kzqai Feb 20 '13 at 16:26
  • I think you should really do a `git svn rebase` instead. It should preserve a linear history according to the documentation at https://git-scm.com/docs/git-svn#git-svn-emrebaseem – Paul Jan 24 '17 at 10:18
1

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
jgeerts
  • 641
  • 8
  • 17
1

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

ndim
  • 35,870
  • 12
  • 47
  • 57
  • That works well in git, but not with svn's linear revision history. So you can get the changes from branch to trunk, but continuing development on the branch afterwards is apparently futile. – Kzqai Feb 01 '10 at 00:14
1

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'.

Bryan Drewery
  • 2,569
  • 19
  • 13