Since this has now started to slowly change, it's probably not a very good idea to pay too much attention to what they're culturally pushing anymore.

Blame, bisect etc. work well with histories with lots of back-and-forth merging, as can be easily seen in Linux, so blaming is definitely not a reason not to do it this way if your project calls for it otherwise. Perhaps one issue with such workflow is that some popular review tools aren't exactly great at letting you review merge conflict resolutions.

(and if you hadn't squashed on merge, short-lived branches wouldn't even "disappear" in the first place as you would still see them decorated in "git log" on commits that were merged in)

The primary value of commit history comes from blame, bisect and corresponding commit messages. There's no reason to "treat PRs as atomic changes to the code base", commits are already supposed to be that and PRs are groups of commits (sometimes groups of size 1, but often not).

> When I mean "squash on merge", I mean the commit history is fully present in the PR for full scrutiny.

And when you merge the set of commits prepared by the author for review in, you get both "summations" and individual commits stored in the commit graph (where their place is) and you get to choose which way you want to view them at retrieval time without having to dig up things outside of the repository. Sometimes it's useful to see the summations only ("--first-parent"), sometimes you only want the individual atomic changes ("--no-merges"), sometimes you want to see them all but visually grouped together for clarity ("--graph"). When you squash on merge, you just give all that flexibility away for no good reason.

It's a commit graph, not a commit linked list, so treat is as such.

You can often also access equivalent functionality by platform APIs. For example, GitHub has event API which you can use to check what a ref has pointed to previously.

A PR is a group of commits, just utilize that when you need it.

When I work on something, I commit often and use the commit graph as a undo tool on steroids. I can see what I tried, I can cherry-pick or revert stuff while experimenting, I can leave promising but unfinished stuff to look at later, or I can just commit to have a simple way to send stuff to CI, or a remote backup synced between machines.

Once I'm done working on something, it's time to take a step back, look at the big picture, see how many changes my experiments have actually yielded, separate them, describe and decide whether they go to review together or split in some way, as sometimes working on a single thing requires multiple distinct changes (one PR with multiple commits), but sometimes working in a single session yields fixes for multiple unrelated issues (several PRs). Only then it gets presented to the reviewer.

It just happens that I can do both these distinct jobs with a single tool.

And here's a slightly smaller one which isn't about "miscellaneous fixes": https://lore.kernel.org/netdev/20260408122027.80303-1-xuanzh...

Some of these commits even get reviewed by different maintainers before being merged, which is common when a patchset touches several subsystems at once.

Things that aren't referenced by anything anymore will eventually get garbage collected and actually destroyed, but you can just keep a reference somewhere to prevent that from happening if you need. Or even disable garbage collection completely.

Looks like people's fears about git come just from not knowing what it does.

Having atomic commits lets you actually benefit from having them. Suddenly you don't have to perform weird dances with interconnected PRs with dependencies as "PR too big" is not such a problem anymore as long as commits are digestible; you can have things property bisectable; you can preserve shared authorship; you can range-diff and have a better view on what and how changed between review passes, and so on...

The unit of change is commit, and PRs group commits you want someone to pull. If you don't want or need any of that, you're just sending a patch file in a needlessly elaborate way.

I use it like that too and yet the reviewers don't get to see these commits. Git has very powerful tools for manipulating the commit graph that many people just don't bother to learn. Imagine if I sent a patchset to the Linux Kernel Mailing List containing such "fix typo", "please work now", "wtf" patches - my shamelessness has its limits!

I meant "shared place" as an open review request or a shared branch rather than shared underlying infrastructure. Shared by people's minds.

It's also obvious to me that at this point I'm never going to reach the virtuoso level even if I really wanted to, but so what? I suck, but whenever I manage to play something that I couldn't before it brings me joy.

Squash-merge workflows are stupid (you lose information without gaining anything in return as it was easily filterable at retrieval anyway) and only useful as a workaround for people not knowing how to use git, but git stores the author and committer names separately, so it doesn't matter who merged, but rather whether the squashed patchset consisted of commits with multiple authors (and even then you could store it with Co-authored-by trailers, but that's harder to use in such oneliners).