> “This replacement effort exponentially increased message storage capacity and operator response times for critical nuclear command and control message receipt and processing.”
Glad to know operator response times have exponentially increased!
> that rebasing as part of a workflow was part lack of discipline when creating commits
Because we have rebase, there is not as much need for discipline when creating commits, because you can change change them later.
> and part desire to hide work that is incomplete or "imperfect"
When I do any kind of work, I usually submit the finished work to whomever needs it. It's not hiding, it's just giving people what they need.
When I use `rebase -i` in my workflow to alter my commit history, it's almost always for the purpose of helping code review. I want my commits to lead a reviewer logically down a path that helps them understand the role each change makes in a push request.
What you are describing is not what the author of the article is advocating, which is `git merge --squash`.
What you've described -- committing often and later combining commits together into cohesive units that don't break tests -- is a lot like how I work. I use `git rebase -i` for this; never `git merge --squash`.
I don't think I will ever understand people's fascination with squashing feature branches.
Develop on a branch, yes; rebase the branch instead of merging in master, sure. But why delete the history by squashing, when a merge into the mainline can look just as neat without requiring history to be deleted.
The argument that I've heard is "so that I don't have to all of that detailed history." But that is a display problem, not an argument for removing history.