How not to use merge --squash
Merging branches using "--squash" has its advocates. The main (and also - the only) reason for squashing is to keep the history clean, but one can of course argue whether a commit containing a whole feature is easier to understand than a "dirty" history of incremental commits.
Leaving the argument aside, there is one thing that you certainly shouldn't do and that is squashing commits between long-lived branches. What's that? Suppose you have 2 main-ish parallel branches -- those can be 2 maintenance release branches, current and vNext development branches, you name it. Or maybe let me name it: alpha and beta. And assume (without loss of generality) that beta is a younger, newer branch - all the changes that happen on alpha need to be merged into beta (but not necessarily the other way round).
Now, let me paint you a picture.
Prolog
Your team has never squashed before so every merge on the repository has only been performed via pull requests with --no-ff option. Today as usual you are told to fix a bug that was discovered on branch alpha. You make a fix, create a pull request and after a successful review [1] you merge it into alpha. A commit 0a has been created. Because the bug also exists in the newer version of the system, you create a PR that merges alpha (with the fix) into beta. A PR is merged using --no-ff into beta the same day. A commit 0b has been created.
The next day
On a daily scrum your team decides that from now on you should merge every PR using only the squash method. You all seem to be happy with the proposal, because you've always thought that linear git history is the best git history [2]. Your today's task -- to create a new feature for the alpha version. You push several commits and create a pull request. You then squash the content of the PR into alpha. A commit 1a is created.
Then, you are told to merge the new stuff into the beta branch. So you create a pull request from alpha to beta. And then you perform the first squash merge into the beta branch. That's how you've created commit 1b.
At the same time your favourite colleague Andrew has been working on his alpha-feature. He created a PR as well and squashed his feature branch into alpha (creating commit 2a) after you had squashed yours. And now he wants to squash 2a into beta. He tries to do that, but hey, there's a conflict! Hmm, you and him have been working on different features, different parts of the system even, so how come the merge is not automatic? "I must have done something wrong" -- he thinks. Or more probably -- "Damn you git, what is your problem today?". So Andrew with a frown on his face abandons the PR, creates an intermediate branch, resolves the conflict by hand locally, pushes the changes on the new branch, makes the PR and then squashes the PR into beta, which results in commit 2b.
A day after
You want to correct another nasty bug on the alpha branch. You fetch all the branches from remote and repeat the necessary steps to create a squash into alpha. All good for now -- commit 3a. Then you try squashing alpha into beta. Conflicts. And to your surprise, some of them are in Andrew's files? But how? You have only added new files, not modified anything! And even more, 2a is a direct parent of 3a and commit 2b has exactly the same diff as 2a!
And that's how we get to the point -- 2a is an ancestor of 3a, but 2b isn't. 2a and 2b are two different commits, they just happen to share the exact same content. The same with commits 1a and 1b that caused Andrew some trouble a day earlier. Git merges commits based on their ancestor tree, not their content. Git does not care [3] that 1a contains the same changes to your foo.txt file as 1b. It cares that the last common ancestor of alpha and beta at that time was commit 0a.
When Andrew tries to merge 2a into beta he wants to merge 2 branches that diverged at 0a and both have the content of foo.txt changed. That’s where the conflict comes from. And then when you try to merge 3a into beta you want to merge 2 branches that… also diverged at 0a but have changes in the foo.txt and bar.txt! The latest common ancestor hasn’t changed and will never do, unless someone finally merges (without squashing!) all the commits that do not exist in beta history. This will finally create a link between the branches that will release your team from neverending merge conflicts. Otherwise, every time you squash a PR from alpha into beta you create one more link in the conflict chain! Try to imagine what would happen if the team merged alpha into beta twice a month and were to discover the problem only after 3 months...