[bmitc]

> This is why I use rebase before PRs, and despise squash. You are not going to remember why you wrote that code that way 2 years from now and all we'll have to understand bugs and identify Chesterton's Fence situations is the deltas and the commit history.

This forces people to work in a very linear fashion that doesn't match how people actually work.

A 400 line commit from a squashed PR should be very manageable when tracing a bug in the main branch, especially if the PR has a good description and review. Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless you now force everyone to bundle perfectly reversable actions in every commit.

[hinkley]

> "fixed, added, deleted"

I'm saying get rid of those before you invite people to look at the code. Keep the 'code review changes' one because that's comedy gold when the PR changes forced on you by some snowflake actually cause a production outage at 2:00 am.

[Joker_vD]

> Having a bunch of "fixed, added, deleted" commits all pushed into main seems like a disaster of noise unless

unless you skip non-merge commits when reading the history of main. And personally, I don't remember needing to read main's history more often than probably once a year, and even then mostly out of curiosity.

Also: having a bunch of "ticket resolved" commits all pushed into main seems like a disaster of noise, compared to simple "release 203", "release 204", etc. series of commits that comprise the main. Squash even further! Just as you don't need to track every small development change inside a feature request, you don't need to track every small feature or fix inside a full release. Right? You write a changelog (if you even write them) using those 400 merge-commits, then squash it into a one commit for you release, bang, clean history.

[hinkley]

> And personally, I don't remember needing to read main's history more often than probably once a year, and even then mostly out of curiosity.

You're probably delegating that work to someone like me who actually figures out what the systemic problem is that caused the same class of bug to make it to production 5 times in the last 3 years. If you're a lead or a principal and still saying this ^ then you need to expand your skillset.

Bad luck doesn't happen very often. Mostly it's blindspots.

I will confess though that the sort of forensics I do is probably not divisable from the fact that I'm also the designated VCS surgeon on every project I've been on since 1998.

[jeremyjh]

Also - at least in GitHub if you squash with the PR merge action in the UI - the original commit history is still available in the ref maintained by the closed PR yet doesn’t clutter your branch or tags namespace.