What's wrong with squash-merges? As long as your merge requests aren't enormous, squash merges keep your commit history clean, instead of being polluted with tons of commits with the comment "fixed typo" when most of the real work is in a single commit or two. When I'm reviewing someone's MR, I do not want to wade through dozens of very minor commits that are probably already fixing the things I would have complained about.
And what's wrong with merge? How do you even use git without merging?
In theory I don't mind them. In practice I've found that I more often encounter a scenario where I wish a change had been split to smaller commits rather than the scenario where there were too many commits to go through.
Anyway... I intended my example as an explicitly anecdotal evidence to counter the seemingly absurd suggestion of using Git without ever using merge. Feels like going back to subversion or CVS.
All companies I worked in for the last 10 years used squash-merges exclusively, combined with trunk-based development and small commits. I don't see anything wrong with that, it's nice to have a history where every other commit is not a merge commit.
Merges make it prohibitively difficult to go back in time because they create alternative versions of history. There are many negative aspects to this, but I will use git-bisect to illustrate the problem.
For more reliable code-bases you want to do the following:
* Run tests on each commit when accepting PRs.
* Be able to remove or edit intermediate commits, if you find that they've created problems afterwards.
* Only have one path from past to the future.
This is so because if want to use git-bisect, and instead of deleting faulty code you reverted it, the command will keep failing on the code that you've already fixed, and there's nothing you can do about it. git-bisect also has to follow one and only path from the past to the future because if you don't, then, at best, you get an combinatorial explosion of possible paths git-bisect may take, and at worst, some of these paths will fail, but others will not.
So, what ends up happening is this: people who use merges are like people who never clean up their apartment. For some it will take longer, than for others, but, inevitably, the apartment will become a filthy mess. But this is just a symptom of people being afraid of not understanding their code, being afraid of making big changes, undoing things committed to long ago.
This fear is usually an indication that people aren't good at the technology they are using. They would be too afraid to delete code because "what if it breaks something?" -- and nobody can tell authoritatively "no it doesn't". In a situation like this any change in technology s.a. using a different version of the same tool, or replacing the tool altogether will be almost impossible to implement because of the fear.
It's also usually very characteristic of places like this to be afraid of knowing / learning the underlying technology, the one that supports the entire company's stack. Eg. if it's a Python shop, then they'd be opposed to writing Python modules in C, even though this is how Python typically works, because they are afraid that they won't understand this code and one day will end up with a "magical" program that sometimes fails, but nobody knows why.
It's also usually the people who won't even try an unpopular technology, even if the benefits were huge, based on their fear of not having expertise to deal with it. Eg. XML schemas are hugely superior to JSON schemas, and if you want to validate your inputs, XML is just a better tool for this, but the company I'm describing will never consider using it because they are afraid of not being able to find people willing to work with DTD / XSL / RNG.
Such a company will never consider self-hosting, and will pay through the nose for the expertise of others, being mortally scared by a prospect of running their own infrastructure.
----
And... this is the majority profile. The problem is, this is not a winner's profile. It's a scrapping-by profile. It puts an individual programmer in the situation where there's no need and no reward for bettering themselves. Where management is antagonistic to programmers because they are in a conflicting situation, where on one hand they want to give customers more stuff, but on the other hand they are too afraid to make more stuff, since it may deprive them of the stuff they already have. So programmers are punished whether they do or whether they don't. It's where cargo cult flourishes. Basically, Dillbert comic before its author went into politics.
For all I know, I once joined a company where the policy was to only do squash-merges. I left from there at the brink of mental breakdown.