The older I get the more I find these discussion as counterproductive as figuring out where to put the bike shed.
I worked in teams that did squash merge and in teams that didn't. And in teams where some did and some didn't, on the same repo. In the grand scheme of things it didn't matter, except for hardliners who had nothing better to talk about.
I agree with your point, but, tangentially, I do find it amusing that "where to put the bike shed" is actually _more_ impactful than what I thought "bike-shedding" referred to (arguing about what _colour_ to paint the bike shed for a nuclear reactor). At least the location of the bike shed actually has some (small) effect on people's commute!
Yep, I agree. In my ideal world, everybody (including me) would have pristine commits that are broken up logically. There wouldn't be small commits created as part of code review to fix things up based on feedback. You'd just have a single "Add feature X" or "Fix bug Y".
However, it's an imperfect world and there are trade-offs. It's hard to train people to do things the right way, and then policing when they do it the wrong way or putting roadblocks in place to make them do it the right way takes energy, and often the benefit is minor. It really depends on how frequently you pore through your history to find an offending bug and a whole bunch of other team policy that isn't directly related to git commits.
I used to spend a lot of energy rebasing so that I could have a beautiful history, but honestly it hasn't benefited me that much. I still rebase, but I'm not so strict about it on my commits, nor others. I'd rather spend my focus and energy elsewhere.
Just do what the team is comfortable with and be flexible.
The question really is whether the team values version control history with good commit messages. A simple test would be to make all commits with the --allow-empty and --allow-empty-message flags which allow you to make commits that don't change any files in the work tree and don't include a commit message.
If the team doesn't see an issue with it, then using those flags should be mandated since what the team is really interested is just snapshots of the codebase. Any associated message (the commit message) is effectively useless and ignored, so why bother even including it?
not only getting older, also getting closer to the project managers point of view gives a different perspective on what does really matter for the project.
Spoiler alert, commit history most likely does not.
I worked in teams that did squash merge and in teams that didn't. And in teams where some did and some didn't, on the same repo. In the grand scheme of things it didn't matter, except for hardliners who had nothing better to talk about.