I'm a release engineer, and I couldn't agree more with the sentiment of this post. I have immense respect for mjd's work (His articles on Perl saved my bacon more than once - _Suffering with Buffering_ and _Coping with Scoping_ in particular) but this workflow just plain stinks and feels like building a house, then demolishing it and picking through the rubble to build a better house you're satisfied with, rather than (as git was designed to do) experimenting off to the side in a branch and only commiting Good Stuff to your 'for real' branch (master or otherwise.)

Assume that while working on your branch you made a few commits which were not perfect (say you wanted to take a day off and you want a commit point to work from when you are back). This all good and fine, you come back get the code working on your branch, make a commit and merge it to the main branch. When one looks at the commit log in the main branch it would list all the commits you have made (even the ones on which the code was not in a good shape). But at the same time the latest commit on main is good and this not a big problem. But if you really want to keep the history in the main branch to look clean and show only good commits, then it is not the case.

Though I don't follow what the author practices, I don't think it is a practice that is done for sake of cleverness. There is a benefit in keeping the history clean in the main branch. My only wish is probably if git allowed one to achieve the same without so many hoops.

Wouldn't git merge --squash do this for you?

Thanks, I had never used the 'squash' option and was unaware of it. I think using 'squash' does helps to the history clean.