LOL, thanks for the checkmark despite my getting a bit ranty 
Of course any team should do whatever they see fit, but I only relatively recently (a couple of years ago) realized that the squashing practice is actually extremely prevalent. git blame is actually an incredibly useful tool on a codebase where the history is intact as it’s effectively an immutable comment that can’t get out of date. Of course it only helps if everyone commits often, and it’s especially helpful if your teammates have good local rebase fu. Unfortunately, I’ve several times seen people online wearing their lack of anything other than the most basic of git knowledge as a badge of honour, so what can you do. Things may not have been this way if Mercurial had won with its objectively better UX, so I do understand, but I’ll continue to shake my fist at the clouds 
sodapopcan
dimitarvp
A bit weird comment from you here IMO. Squashing is a necessary reality for many commercial projects with movements from different people every day. Rebasing sounds good in theory until you see three PRs worth of commits splattered and interspersed in the linear history – after the PRs are done. It’s just confusing. Maybe it’s being more knowledgeable but does not help with readability at all. 
Furthermore, atomic commits are very nice and I approve of them but in a commercial setting they are very often a luxury. So if you can’t have atomic commits then squashed PRs are the second best thing IMO.
Now one thing I don’t like and will never like is how one is forced to go to their (web-based) GIT hosting to drill down on a PR if (and when) needed once git blame points the finger at a squashed PR commit. This should have been a feature of GIT.
LostKobrakai
You can easily have that with git – by not squashing commits, but merging using merge commits.
sodapopcan
In my opinion the best way is to rebase off main then force a merge commit with git merge --no-ff (I believe it can be done in one go with git rebase --merge --no-ff but it’s been a while). This way everything is together and if you write a meaningful message for the merge commit (as opposed to accepting the default) then you can get the “squashed” history with git log --merges. I do actually think github has some blame here as there is no way to do any of this in their UI (there might be a way to filter by merge commits by passing URL params, I’m unsure).
dimitarvp
I’ll openly admit that I haven’t done that in so long that I’ve forgotten how does it look in the repo history… 
I wonder if this is the same that @LostKobrakai said could be done, hmm.
sodapopcan
Yes, sorry, I was sorta both responding to you and expanding on what LKK said but was not very clear about that. So long as you make sure there is always a merge commit you get the best of both worlds. Though I will reiterate that I think it’s best to do the rebase merge so all the commits for a particular feature are grouped together as I agree that that trying to a mangled tree of git history is a terrible experience. A rebased no-ff merge (lordy do I dislike git terminology) ensures you always get a linear history.
dimitarvp
I see that I have forgotten a few things about git which is sad but also normal. Now I have to go look for a visual explanation of what exactly “a rebased no-fast-forward merge” is.
Ideally I would like change-set-kind-of-things where each PR is not squashed; you can still expand it of sorts, like a directory with files. And we can have fully recursive history that way. I have not researched VC systems in a long time, in my mind GIT has won long time ago. But… we also have jujutsu which I liked a lot but just not willing to invest the time and energy to replace git with something that’s one layer above it just yet.
sodapopcan
That’s what I’m describing essentially gets you.
And yes… git terminology 
First off, I was wrong about git rebase --merge --no-ff—there may be a shortcut command but I forget. The long way is:
git checkout feature
git rebase main
git checkout main
git merge --no-ff feature -m "My cool feature"
This creates a merge commit called “My cool feature” with all the commits that got it there grouped below it. You can git show the merge commit to see the diff for the full feature and when you git blame a file, you get the message for the specific commit that introduced it as opposed to a generic message for a feature that took a few days to complete.
Now, if your team is somehow amazing at always submitting bite-sized PRs that’s another story. I have yet to work anywhere that manages to do this.
PS, yes jujutsu looks cool but I still haven’t invested any time. I know it’s currently built of off git but I believe the idea is to eventually drop it as a dependency?
dimitarvp
I have bookmarked this comment, FYI. 
btw you can replace this:
git checkout feature
with this:
git switch feature
It has been a part of GIT for a while now and I am getting used to it and I like it. I am really tired of GIT’s quirky terminology.
