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 br
Would this not be a good case for rebasing your local stuff (<branchpoint>..i
) onto the new master fetched from SVN?
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.
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
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
usersclone
,fetch
anddcommit
directly from the SVN server, and avoid allgit 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
andgit am
, or justdcommit
ing 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.