Comments on: git-svn in the workplace http://www.chrishowie.com/2010/04/01/git-svn-in-the-workplace/ The best laid plans are in my other pants Thu, 01 Dec 2011 15:21:02 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Chris http://www.chrishowie.com/2010/04/01/git-svn-in-the-workplace/comment-page-1/#comment-17396 Chris Fri, 02 Apr 2010 19:17:27 +0000 http://www.chrishowie.com/?p=365#comment-17396 Ah, I haven't used the -i option to rebase to do that -- I'll have to give it a go. As a personal preference, I don't typically squash my commits because I like the complete history to be in SVN. But I'm sure -i will be very useful for altering commit messages before I dcommit. Ah, I haven’t used the -i option to rebase to do that — I’ll have to give it a go. As a personal preference, I don’t typically squash my commits because I like the complete history to be in SVN. But I’m sure -i will be very useful for altering commit messages before I dcommit.

]]> By: Mark http://www.chrishowie.com/2010/04/01/git-svn-in-the-workplace/comment-page-1/#comment-17393 Mark Fri, 02 Apr 2010 17:41:25 +0000 http://www.chrishowie.com/?p=365#comment-17393 I use a similar workflow but as git has many ways do to everything I use a slightly different method. To change a previous commit (assuming you've not done git svn dcommit). Basically, I save up a bunch of local commits as I work and then when I'm done I push them together so that I'm sending relatively coherent commits. I'm sure you know that you can use 'git rebase -i' to squash commits together but you can also use it to edit commits (including commit messages) or to break commits apart. So to change a commit message: $ git rebase -i HEAD~5 # mark the required commit as 'edit' $ git commit --amend # change the commit message $ git rebase --continue Repeat until happy then: $ git svn dcommit I'm not aware of any real difference between the two approaches - I like mine as I get to look at the list of commit messages and choose the ones I want to change (and as I'm often squashing commits together at the same time it all fits together well for me). cheers, -mark I use a similar workflow but as git has many ways do to everything I use a slightly different method. To change a previous commit (assuming you’ve not done git svn dcommit). Basically, I save up a bunch of local commits as I work and then when I’m done I push them together so that I’m sending relatively coherent commits. I’m sure you know that you can use ‘git rebase -i’ to squash commits together but you can also use it to edit commits (including commit messages) or to break commits apart. So to change a commit message:

$ git rebase -i HEAD~5
# mark the required commit as ‘edit’
$ git commit –amend
# change the commit message
$ git rebase –continue

Repeat until happy then:

$ git svn dcommit

I’m not aware of any real difference between the two approaches – I like mine as I get to look at the list of commit messages and choose the ones I want to change (and as I’m often squashing commits together at the same time it all fits together well for me).

cheers,
-mark

]]>