Squashed Commits and Reverts

[chickenandpork]

Hey Eli; didn't mean to dirty up a PR too much... kinda hard to connect over GH.

The revert thing with Squashed-commits: the immediate response for some large orgs is to immediately revert whatever PR shows failure. If you have fairly atomic PRs, where each commit apparently works, then a failure can be chased down with a git bisect run. When you don't have that, and you're stitching branches together as a merge on commit, then bisect is lost as a tool (because every commit seems to break the build, and a binary search doesn't work). Additionally, if you stitch 12 commits in, and there's a failure, which one broke things? Revert is possible as a PR that's the opposite of the sum of the commits in a previous PR, but I've had strangeness on merge, and revert doesn't quite get back.

... so I tend to recommend fairly atomic commits, one-per-PR.

Additionally, squashed commits and the Semantic Commit messages you're already doing allow tools like googleapis/release-please-action which I use to be lazy.

[lishaduck]

Hey Eli; didn't mean to dirty up a PR too much... kinda hard to connect over GH.

You're good, it's mostly my fault for trying to keep code stuff on GH when it's clearly not the best platform for just about anything (no plans to change that policy though, I like keeping it separate).

The revert thing with Squashed-commits: the immediate response for some large orgs is to immediately revert whatever PR shows failure. If you have fairly atomic PRs, where each commit apparently works, then a failure can be chased down with a git bisect run. When you don't have that, and you're stitching branches together as a merge on commit, then bisect is lost as a tool (because every commit seems to break the build, and a binary search doesn't work). Additionally, if you stitch 12 commits in, and there's a failure, which one broke things? Revert is possible as a PR that's the opposite of the sum of the commits in a previous PR, but I've had strangeness on merge, and revert doesn't quite get back.

I love love love git bisect! Too many people don't know about it.

... so I tend to recommend fairly atomic commits, one-per-PR.

Amen! Yeah, I use atomic commits 99% of the time, I'm working on getting the repo building right now so I can make an actual release, and it only works on main. So it's pretty sloppy right now. Once I get something fairly buildable, I'm probably going to clean it up (pretty please don't PR to help until I'm done! That'd be a pain.)

Additionally, squashed commits and the Semantic Commit messages you're already doing allow tools like googleapis/release-please-action which I use to be lazy.

I actually kinda hate semantic commit-based release bots because I like my changelogs to meaningful, but I find commit-based bots mostly just end up dropping your git log content into the changelog (changesets being the exception, but it's pretty yarn-centric). But I do love categorizing things, and forcing categorization also forces commits to remain lean and focused, I use semantic commits anyway. And no hate on automated releases either, they're really nice—when I can make the changelog. 😛

---

Anyway, I think we're in agreement?

[chickenandpork]

Yeah, I think we're strongly in agreement -- I was worried you weren't, and trying to share advice. You were clearly all over it :)