> I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later.

I did git bisect exactly zero times in my life.

> But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.

I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences?

"Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?

Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame.

IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.

That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?

Actually, what I usually do in Github is set the PR branches to delete when you squash-merge the PR, but then the PR always has an "undelete branch" button you can use forver in case you want to look at the details of the branch and don't have a local copy of the branch.

Interesting, didn't know about that Github functionality.

I'd like to not depend that much on Github, and instead I'm thinking about having some kind of archival repo where noisy boring historical stuff can be saved (but I'd delete the branches in the main repo). Or renaming historical branches, eg adding an "old/" prefix.

That’s what I do, and I find this talk about “throwing away” code history baffling. It’s version control. Git branching is cheap.

I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)

Imagine a feature in git, where when you merge, you get a single new commit on the main branch like you want, where the message could describe the changes in summary, like you want. But also: the commit contains a reference to the source branch so you can easily find it back, break it down, bisect into it, all without having to leave git or rely on data stored at 3d parties. That would be pretty neat! It's like, the best of both worlds, but all inside git!

Well. That's what a merge commit is.

Your approach is nearly identical to creating a merge commit, except the pointer to the second parent (the "original branch") is indirectly recorded via the PR link, instead of directly inside git.

If you create merge commits, then you have your "clean main branch" (via git log --first-parent), as well as the extended history with all the source commits (via git log). And as a bonus, merge commits are supported by every git host, and they work the same in all of them.

I think the whole "squash merge vs merge commit" discussions would be a lot less prevalent if --first-parent would be how git and git hosts displayed commit histories by default. :(

> So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common.

I want my commits to reflect the evolution of the theory of the program, not a chronological log of my reflection and attempts. In my local branches I snapshot things that only matters to my working process. And before sharing, I make sure that the commits are atomic with a proper description.

When sending a report, do you also send all the post-it, the notebook with your notes, the books with the highlights , your conversation with your colleagues, your web history? I don’t think you do. My local history have commits that reflect my working process which can be messy. Before sharing I tidy them, so that the changes are easily understood.

> entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling

A PR is supposed to be atomic if you’re using squash and merge. Bundling different changes is the antipattern here, not the squash and merge.

But do these intermediary commits run? I wouldn't mind making smaller commits, but usually wait until the changes result in a bunch of code that compiles and does what it should. It sounds as if you do checkpoints that don't necessarily result in working code or pass tests. Not that that is wrong, but it is a very different philosophy. I usually expect what I check out to compile and sort of work. I can't really pick up somebody else's train of thought midway.

> So many of these things would have been really painful to find if I'd had to sift through every line of a big commit.

> So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling.

> But yeah, there are plenty of people like the parent in that camp

I'm confused. The parent doesn't want big commits but rather, as they wrote twice, commits that are small, atomic and without noise. So presumably "fix typo" would be removed during rebase but "rename function" would stay and be separate from "implement logic".

I guess the difference between the parent and me is that I’ve been around long enough to see my share of “fix typo “ and “remove logging “ commits that accidentally removed the line above or below.

That’s the commit I want to find six months later when the SVG text is blurry because we’re no longer forcing opacity to 1.0 at the end of a transition.