Is git-svn dcommit after merging in git dangerous?

Question

My motivation for trying out git-svn is the effortless merging and branching. Then I noticed that man git-svn(1) says:

Running git-merge or git-pull

Answer 1

Rebase the local git branch onto the master git branch then dcommit and that way it looks like you did all those commits in sequence so svn people can see it linearly as they are accustomed to. So assuming you have a local branch called topic you could do

git rebase master topic

which will then play your commits over the master branch ready for you to dcommit

Answer 2

Simple solution: Remove 'work' branch after merging

Short answer: You can use git however you like (see below for a simple workflow), including merge. Just make sure follow each 'git merge work' with 'git branch -d work' to delete the temporary work branch.

Background explanation: The merge/dcommit problem is that whenever you 'git svn dcommit' a branch, the merge history of that branch is 'flattened': git forgets about all merge operations that went into this branch: Just the file contents is preserved, but the fact that this content (partially) came from a specific other branch is lost. See: Why does git svn dcommit lose the history of merge commits for local branches?

(Note: There is not much that git-svn could do about it: svn simply doesn't understand the much more powerful git merges. So, inside the svn repository this merge information cannot be represented in any way.)

But this is the whole problem. If you delete the 'work' branch after it has been merged into the 'master branch' then your git repository is 100% clean and looks exactly like your svn repository.

My workflow: Of course, I first cloned the remote svn repository into a local git repository (this may take some time):

$> git svn clone <svn-repository-url> <local-directory>

All work then happens inside the "local-directory". Whenever I need to get updates from the server (like 'svn update'), I do:

$> git checkout master
$> git svn rebase

I do all my development work in a separate branch 'work' that is created like this:

$> git checkout -b work

Of course, you can create as many branches for your work as you like and merge and rebase between them as you like (just delete them when you are done with them --- as discussed below). In my normal work, I commit very frequently:

$> git commit -am '-- finished a little piece of work'

The next step (git rebase -i) is optional --- it's just cleaning up the history before archiving it on svn: Once I reached a stable mile stone that I want to share with others, I rewrite the history of this 'work' branch and clean up the commit messages (other developers don't need to see all the little steps and mistakes that I made on the way --- just the result). For this, I do

$> git log

and copy the sha-1 hash of the last commit that is live in the svn repository (as indicated by a git-svn-id). Then I call

$> git rebase -i 74e4068360e34b2ccf0c5869703af458cde0cdcb

Just paste sha-1 hash of our last svn commit instead of mine. You may want to read the documentation with 'git help rebase' for the details. In short: this command first opens an editor presenting your commits ---- just change 'pick' to 'squash' for all those commits that you want to squash with previous commits. Of course, the first line should stay as a 'pick'. In this way, you can condense your many little commits into one or more meaningful units. Save and exit the editor. You will get another editor asking you to rewrite the commit log messages.

In short: After I finish 'code hacking', I massage my 'work' branch until it looks how I want to present it to the other programmers (or how I want to see the work in a few weeks time when I browse history).

In order to push the changes to the svn repository, I do:

$> git checkout master
$> git svn rebase

Now we are back at the old 'master' branch updated with all changes that happened in the mean time in the svn repository (your new changes are hidden in the 'work' branch).

If there are changes that may clash with your new 'work' changes, you have to resolve them locally before you may push your new work (see details further below). Then, we can push our changes to svn:

$> git checkout master
$> git merge work        # (1) merge your 'work' into 'master'
$> git branch -d work    # (2) remove the work branch immediately after merging
$> git svn dcommit       # (3) push your changes to the svn repository

Note 1: The command 'git branch -d work' is quite safe: It only allows you to delete branches that you don't need anymore (because they are already merged into your current branch). If you execute this command by mistake before merging your work with the 'master' branch, you get an error message.

Note 2: Make sure to delete your branch with 'git branch -d work' between merging and dcommit: If you try to delete the branch after dcommit, you get an error message: When you do 'git svn dcommit', git forgets that your branch has been merged with 'master'. You have to remove it with 'git branch -D work' which doesn't do the safety check.

Now, I immediately create a new 'work' branch to avoid accidentally hacking on the 'master' branch:

$> git checkout -b work
$> git branch            # show my branches:
  master
* work

Integrating your 'work' with changes on svn: Here is what I do when 'git svn rebase' reveals that others changed the svn repository while I was working on my 'work' branch:

$> git checkout master
$> git svn rebase              # 'svn pull' changes
$> git checkout work           # go to my work
$> git checkout -b integration # make a copy of the branch
$> git merge master            # integrate my changes with theirs
$> ... check/fix/debug ...
$> ... rewrite history with rebase -i if needed

$> git checkout master         # try again to push my changes
$> git svn rebase              # hopefully no further changes to merge
$> git merge integration       # (1) merge your work with theirs
$> git branch -d work          # (2) remove branches that are merged
$> git branch -d integration   # (2) remove branches that are merged
$> git svn dcommit             # (3) push your changes to the svn repository

More powerful solutions exist: The presented workflow is simplistic: It uses the powers of git only within each round of 'update/hack/dcommit' --- but leaves the long-term project history just as linear as the svn repository. This is ok if you just want to start using git merges in small first steps in a legacy svn project.

When you become more familiar with git merging, feel free to explore other workflows: If you know what you are doing, you can mix git merges with svn merges (Using git-svn (or similar) just to help out with svn merge?)

Answer 3

A safe way to merge svn branches in git is to use git merge --squash. This will create a single commit and stop for you to add a message.

Let's say you have a topic svn branch, called svn-branch.

git svn fetch
git checkout remotes/trunk -b big-merge
git merge --squash svn-branch

at this point you have all the changes from the svn-branch squashed into one commit waiting in the index

git commit

Answer 4

Creating local branches is definitely possible with git-svn. As long as you're just using local branches for yourself, and not trying to use git to merge between upstream svn branches, you should be fine.

I have a "master" branch that I use to track the svn server. This is the only branch that I dcommit from. If I'm doing some work, I create a topic branch and work away on it. When I want to commit it, I do the following:

1. Commit everything to the topic branch
2. git svn rebase (resolve any conflicts between your work and svn)
3. git checkout master
4. git svn rebase (this makes the next step a fast-forward merge, see Aaron's comments below)
5. git merge topic_branch
6. resolve any merge conflicts (there shouldn't be any at this point)
7. git svn dcommit

I also have another situation where I need to maintain some local changes (for debugging) that should never be pushed up to svn. For that, I have the above master branch but also a branch called "work" where I normally do work. Topic branches are branched off work. When I want to commit work there, I checkout master and use cherry-pick to pick the commits from the work branch that I want to commit to svn. This is because I want to avoid committing the three local change commits. Then, I dcommit from the master branch and rebase everything.

It is worthwhile running git svn dcommit -n first to make sure that you are about to commit exactly what you intend to commit. Unlike git, rewriting history in svn is hard!

I feel that there must be a better way to merge the change on a topic branch while skipping those local change commits than using cherry-pick, so if anybody has any ideas they would be welcome.

Answer 5

Actually, I found an even better way with the --no-ff option on git merge. All this squash technic I used before is no longer required.

My new workflow is now as follows:

• I have a "master" branch that is the only branch that I dcommit from and that clone the SVN repository (-s assume you have a standard SVN layout in the repository trunk/, branches/, and tags/):

  git svn clone [-s] <svn-url>
  

• I work on a local branch "work" (-b creates the branch "work")

  git checkout -b work
  

• commit locally into the "work" branch (-s to sign-off your commit message). In the sequel, I assume you made 3 local commits

  ...
  (work)$> git commit -s -m "msg 1"
  ...
  (work)$> git commit -s -m "msg 2"
  ...
  (work)$> git commit -s -m "msg 3"
  

Now you want to commit onto the SVN server

• [Eventually] stash the modifications you don't want to see committed on the SVN server (often you commented some code in the main file just because you want to accelerate the compilation and focus on a given feature)

  (work)$> git stash
  

• rebase the master branch with the SVN repository (to update from the SVN server)

  (work)$> git checkout master
  (master)$> git svn rebase
  

• go back to the work branch and rebase with master

  (master)$> git checkout work
  (work)$> git rebase master
  

• Ensure everything is fine using, for instance:

  (work)$> git log --graph --oneline --decorate
  

• Now it's time to merge all three commits from the "work" branch into "master" using this wonderful --no-ff option

  (work)$> git checkout master
  (master)$> git merge --no-ff work
  

• You can notice the status of the logs:

  (master)$> git log --graph --oneline --decorate
  * 56a779b (work, master) Merge branch 'work'
  |\  
  | * af6f7ae msg 3
  | * 8750643 msg 2
  | * 08464ae msg 1
  |/  
  * 21e20fa (git-svn) last svn commit
  

• Now you probably want to edit (amend) the last commit for your SVN dudes (otherwise they will only see a single commit with the message "Merge branch 'work'"

  (master)$> git commit --amend
  

• Finally commit on the SVN server

  (master)$> git svn dcommit
  

• Go back to work and eventually recover your stashed files:

  (master)$> git checkout work
  (work)$> git stash pop
  

Answer 6

Greg Hewgill answer on top is not safe! If any new commits appeared on trunk between the two "git svn rebase", the merge will not be fast forward.

It can be ensured by using "--ff-only" flag to the git-merge, but I usually do not run "git svn rebase" in the branch, only "git rebase master" on it (assuming it is only a local branch). Then afterwards a "git merge thebranch" is guaranteed to be fast forward.