tags:

views:

3208

answers:

3

According to the manual, git dcommit “will create a revision in SVN for each commit in git.” But is there a way to avoid multiple Subversion revisions? That is, to have git merge all changes prior to performing the svn commit?

+11  A: 

If you work on a branch in git, you can git-merge --squash, which does that within git. You could then push that one squashed commit to SVN.

Of course, lots of small commits are good, so why would you want to squash them?

davetron5000
Thanks! (Normally I would want lots of small commits, but this concerns a client project where I and my partner need to frequently push changes between each other, and often even changes that would break the trunk.)
plindberg
Why don't you both work on the same (svn) branch, then?
Knut Eldhuset
I use lots of small commits to make it easy to track changes; when I dcommit to the svn server, we generate an email for each SVN commit. I'd rather do the extra work of merging back to master with squash for "logical unit" commits and save everyone a few emails.
cbowns
+13  A: 

The command git rebase -i can do this, and more. This command is extremely powerful, so it's good to make friends with it.

The syntax is: git rebase -i <commit ID>. This brings up your text editor, with options (and instructions) for modifying all the commits up to (not including) the given ID.

For example, to modify the previous 5 commits, you can do this:

git rebase -i HEAD~5

Or if your SVN branch is called "svn/trunk", then this syntax is good too:

git rebase -i svn/trunk

Then a text editor window will pop up. To squash everything, change the first word of every line after the first from "pick" to "squash" (If this sounds confusing- it will make more sense when you see it). Then save and close the editor. You'll then have a chance to edit the commit message for the squashed commit.

Among the other things you can do with git rebase -i, are reordering commits, squashing commits in different ways, and removing commits.

I use this command constantly; it's a killer feature of Git.

andy
+2  A: 

Ryan Tomayko wrote a bit about git rebase -i, which he said:

…[it's] a bit like git commit --amend hopped up on acid and holding a chainsaw – completely insane and quite dangerous but capable of exposing entirely new states of mind. Here you can edit, squash, reorder, tease apart, and annotate existing commits in a way that’s easier and more intuitive than it ought to be.

I have a tendency to commit often in git, but don't necessarily want to dcommit every commit to svn, and squashing all my work makes just as little sense. I'm trying it now to reorder and squash a few together into more logical commit units now.

cbowns