Git: Please Stop Squash Merging
Lucas Seiki Oshiro explains the drawbacks of squash merging in Git, debunking the belief that it condenses changes effectively. He clarifies Git's inner workings and the implications of squash merging.
Read original article
Lucas Seiki Oshiro discusses the practice of squash merging in Git, emphasizing that it may not be as beneficial as commonly believed. He delves into the misconception that commits store changes when, in reality, they store snapshots. Oshiro explains the inner workings of Git, detailing how objects like blobs, trees, and commits function. He clarifies the process of merging in Git, including fast-forwards and three-way merges. The article challenges the notion that squash merging condenses changes into a single commit on the default branch, highlighting that it fundamentally alters the parentage of commits. Oshiro points out that squash merging is not a built-in Git command and requires two separate commands to achieve. He concludes by distinguishing between a squash merge commit and a true merge commit, noting that the former has only one parent, leading to a different referencing structure.
Related
A specification for adding human/machine readable meaning to commit messages
The Conventional Commits specification simplifies commit messages for clarity and automation. It categorizes changes, aids in generating changelogs, and promotes organized development practices without strict case sensitivity requirements.
I kind of like rebasing
People debate Git workflows, favoring rebasing for a linear history. Redowan Delowar prefers rebasing to consolidate changes and maintain a clean commit history. They discuss interactive rebasing benefits, squashing commits, handling conflicts, and offer practical tips.
Software Engineering Practices (2022)
Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.
Git Workflows for API Technical Writers
Technical writers encounter challenges in maintaining API documentation aligned with evolving designs. Git workflows provide version control and collaboration benefits. Strategies like merging copy improvements, code annotations, and OpenAPI overlays enhance documentation quality. Involving writers in API design ensures user-centric content. Storing docs in separate repositories can resolve Git conflicts.
My .gitconfig File Dissected
The article delves into .gitconfig file breakdown, covering user details, GPG key signing, Git aliases, and workflow optimization tips. Encourages readers to customize their .gitconfig for enhanced Git usage.
5 commentsSo what if git doesn't have a single command to 'squash-merge'? It doesn't natively support a 'pull request' workflow either. Code forges build convenience functionality on top of git. If I didn't have the 'squash merge' feature I'd just use an interactive rebase to fixup/squash the branch's commits before doing a fast-forward-only merge, because I don't want a git history littered with meaningless noise.
And the 'fewer commits are better so that must mean no commits is best' argument is such an obvious slippery slope fallacy, come on man. Do you seriously think this kind of argument will fly in real life? You are just going to annoy the crap out of everyone. We don't squash and rebase because we want fewer commits, we do it because we want fewer meaningless noise commits. Do you want to preserve all your editor keystrokes, like backspaces, moving code around, copy-pasting, etc., before committing? If you don't, then you obviously don't want to track any history, right? Of course not, that's silly. That's what your argument is like.
I don't want my repo history littered with meaningless noise like these merge commit messages:
* Merge pull request #1234 from bob/implement-foo
* Implement foo (pull request #1234)
I also don't want a commit history that looks like London's tube system map. Please, keep the history linear so that myself and future team members can quickly focus on the parts that interest them, after just a glance, and don't have to spend time decoding the tangled mess of interlocking branch histories. Much appreciated!
I understand that not all organizations work like this, but that is my point: there is nuance. Blanket statements like these are not productive. The author seems frustrated that people still use squash merge, and just assumes that it's because people just don't understand how git works.
I've worked with quite a few organizations and many of them use squash merges. Commits are often made because of a failed lint check needs a new formatting commit, addressing some comments to tweak some minor details, or even basic documentation changes. The pull request on GitHub ends up being the source of truth for the change, not the git log, and squash merges do a great job at keeping a single pointer to the parent pull request. Ignoring these nuances and how git interacts with other tools amounts to telling the user they're holding it wrong.
Clearly, squash merging does something useful but the author is totally not interested and declares that squash merging is good for one exceptionally specific use case, the only true clean commit history is not using git at all, and the problem exists between the keyboard and the computer.
The result: the git repository (at least in Stash) slowed to a crawl, because the comments to the commits were several hundred MiB. It was nuts. Never seen a git hosting site go that slow before.
Actually had to replace the whole repo with another, more or less wiping history (kept the old slow repo just in case, of course), and disabling that damn squash-merge button.
Related
A specification for adding human/machine readable meaning to commit messages
The Conventional Commits specification simplifies commit messages for clarity and automation. It categorizes changes, aids in generating changelogs, and promotes organized development practices without strict case sensitivity requirements.
I kind of like rebasing
People debate Git workflows, favoring rebasing for a linear history. Redowan Delowar prefers rebasing to consolidate changes and maintain a clean commit history. They discuss interactive rebasing benefits, squashing commits, handling conflicts, and offer practical tips.
Software Engineering Practices (2022)
Gergely Orosz sparked a Twitter discussion on software engineering practices. Simon Willison elaborated on key practices in a blog post, emphasizing documentation, test data creation, database migrations, templates, code formatting, environment setup automation, and preview environments. Willison highlights the productivity and quality benefits of investing in these practices and recommends tools like Docker, Gitpod, and Codespaces for implementation.
Git Workflows for API Technical Writers
Technical writers encounter challenges in maintaining API documentation aligned with evolving designs. Git workflows provide version control and collaboration benefits. Strategies like merging copy improvements, code annotations, and OpenAPI overlays enhance documentation quality. Involving writers in API design ensures user-centric content. Storing docs in separate repositories can resolve Git conflicts.
My .gitconfig File Dissected
The article delves into .gitconfig file breakdown, covering user details, GPG key signing, Git aliases, and workflow optimization tips. Encourages readers to customize their .gitconfig for enhanced Git usage.