Thou Shalt Not Lie: git rebase, ammend, squash, and other lies

&#62; [If you use git merge --squash some-branch] [w]hen a QA person or your boss says, "Hey, is some-feature {merged into QA, deployed}" you have to resort to `git log` spelunking.<p>Of course you shouldn't use merge --squash in that context. That doesn't mean you should never use merge --squash. You just shouldn't use it to rewrite public history. Do you have a local branch in which you fixed some bugs and which branch has not been pushed out to the world and would you like to use merge --squash to merge it into master? Go for it! But if that branch _has_ been pushed out to the world, just use a regular merge.<p>The fundamental practice the author is arguing against is rewriting public history. But instead of making that point, he makes these sensationalist, dogmatic assertions that rebase, merge --squash and commit --amend are evil and should never be used. Until the end of the article, where he finally admits that really what he (correctly) has a problem with is rewriting public history.<p>OK, fine. Just title the article "You shouldn't rewrite public history".

Linus thinks that it's fine to rewrite history on a <i>private</i> branch: <a href="http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html" rel="nofollow">http://www.mail-archive.com/dri-devel@lists.sourceforge.net/...</a><p>&#62; but instead of committing all of your work as you have come to it naturally, you decide to break your work up into several small, "logical" commits. This makes you look good, but it's a lie.<p>No. Breaking your work up into several small, "logical" commits is exactly the right thing to do.<p>I find this very useful when doing experimental coding: when I don't really know where I'm going or if my changes will work. I end up with a pile of commits that <i>do</i> break tests and thus bisect etc, before ending up with something that works. Reworking this <i>private</i> branch is exactly the right thing to do.<p>This is in fact the exact model that open source development has used for years. Try submitting a patch series for inclusion in the kernel which include a bunch of mistakes that you've later corrected (as happens naturally during development) and see what happens. You'll be asked to rework it, since it makes it harder to review.<p>Take a look at the Linux git tree and find me a single merge commit where the branch being merged contains mistakes and corrections. You won't find one. You will find plenty of regression fixes, but these are there because by this time the commits were public and couldn't be fixed retrospectively using a rebase without rewriting public history (which would obviously cause all sorts of problems).

I think this depends a lot on your team, your practices, and the way you use source control. At the old job, source control (mostly SVN) was <i>essential</i> for figuring out why a new change to the framework broke a customer-specific customization written six years ago by someone no longer with the company. The company culture was to keep commits and merges so clean they were almost releases in themselves. (It took me, ahem, quite some time to adapt to that style of working -- coming as I did from not using source control at all.)<p>If they had used git, they would <i>totally</i> have approved use of rebase for optimizing readability/understandability of commits for the beleaguered maintenance engineer in 2016 trying to figure out what why what we did today (in 37 separate incremental commits) just interacted with new code and blew up $MAJOR_UNIVERSITY's payroll system.<p>I follow very, very different practices when developing by myself. I largely leave the history as it is, warts and all. If in the course of trying to fix a bug I make five exploratory commits and on the fifth one finally find the magic that works, then history just happens to include five increasingly frustrated commit notes.

Core disconnect: what is source controls role: is it a journal of all history, or is it a tool to find code.<p>I fall on the tool side, which means I rebase &#38; amend and keep history semantically organized, and such. All that makes it easy later to find exactly where I made XYZ change. BUT, I admit that it does ruin the journal aspect of every change. rebase -i does in fact change history, and can make things appear out of order.<p>I think it's ok, the author doesn't.

Look, the world doesn't need to know it took me 13 attempts to get the patch right and passing all its tests. The world really doesn't need to see the childish mistake I made on attempt 5 or the cuss words I was using in the #define on attempt 8. Just take the sausage and skip the tour of the factory.

Bah, that's bullshit. These are Git features and meant to be used, and these are part of the reason Git rocks so great.<p>It's not lying, it's cleaning up. History rewriting is assembling all the intermediate crap into a comprehensible patch that as an added bonus also comes with a hindsight, or keeping sense in maintaining your work-in-progress on top of some other branch by continuous rebasing.<p>It's not lying, it's making sense. It's the same thing <i>why you don't save your Emacs editing history to have someone else replay it</i> to produce the source file. You just save the source file because you've spent time doing work to eventually produce something that makes sense. You don't want to bother other people with your errors. It's of no value to them.<p>However, the time you do <i>not</i> want to do this with public commits. Anything that you have pushed or someone has pulled is public. Anything that flies out of your local nest shall become immutable.

Grow up. It's source control, not marriage. Sometimes it makes sense to make bigger commits (there is lots of reasons to sometimes present the checkin in a manner other than 1000 little incremental fixes; its a naive techie who thinks otherwise) or fix those you have made. Get over it and relax; don't try to add morals to source control.

However if you do compile and/or run the tests it makes a lot of sense to make logical commits instead of monolithic commits of changes that are not interdependent. And --amend ing a commit message to fix a typo before pushing it is completely harmless.<p>There's some valid bits in there but commandment-from-on-high writing style is pretty offputting.

Fictions are useful. Source is meant to tell a story to the other developers, and only incidentally to control a computer. The history of development is just as much a part of this story. There is a balance between making it clear and making it reflect what happened in a way that's not misleading, but if each release in the new history is actually reasonably tested, I have no problem rewriting private history.

If rewriting private history is a lie, is rewriting URLs also a lie? Should we all expose ugly /app.cgi?foo=bar?action=edit URLs because we shouldn't lie? Ss fiction a lie?<p>If all that is a "lie", I'll happily lie to outsiders to present them a nicer image, as long as no harm is done that way.

Though Shalt Not Lie: a stupid article title, idiotic advice, and other lies