Dec 10, 2010
I have written before about my workflow in Fedora. This workflow includes a relatively high number of rebasing where I squash last two commits into one. I use it to quickly refine and test patches. My history then usually looks something like this:
Edit: Benjamin suggested to use "fixup" instead of "squash". This is new thing in git 1.7+. For more information on this see this blogpost.
$ git log --format=oneline --decorate=no | head -3 2db8eacd7f7c20be88824caae5f5af16b9520d34 temp 443bb0f019c87f0090bb9da295a019c0eee23729 Add conditional BRs to enable ff merge between f14 b4c602f9f044598544cff3d68710f68b9447ea0f Fix installation of pom files for artifact jarsWhere 443bb0f is my first attempt at the fix and 2db8eac is a fixed fix :-). Before pushing this into upstream repository I usually squash last two commits to look like this:
$ git log --format=oneline --decorate=no | head -2 f852c3e260d21bbc642f861e6fa6ea62caa7b69b Add conditional BRs to enable ff merge between f14 b4c602f9f044598544cff3d68710f68b9447ea0f Fix installation of pom files for artifact jarsI used to do it manually, but I do it often enough it made sense to automate this. So without further ado:
#!/bin/sh export EDITOR="sed -i '2s/pick/squash/;/# This is the 2nd commit message:/,$ {d}'" git rebase -i HEAD~2Save this somewhere inside your $PATH and chmod +x (or set up shell alias). Then just running this will automatically squash last two commits, using HEAD~1 commit message and discarding last commit message. No warranties though :-)
Edit: Benjamin suggested to use "fixup" instead of "squash". This is new thing in git 1.7+. For more information on this see this blogpost.
You want "fix" instead of "squash" in git rebase -i
Yeah, that's a new thing since git 1.7 though. It seems like I should start reading git changes after each release :-)