Ironically, you have a very strong opinion on people with strong opinions. Going as far as saying if you have a strong opinion on how to use git means you're a junior is a bit extreme, in my opinion.
I’m sure you could change his mind with a good reason. What reasoned argument can you give as to why it would be better to have a strong opinion about why one type of merge is always better.
Maybe you’ve seen the long term affects of squashing commits in several different contexts, and it always leads to a poor outcome eventually. Sure there might still be reasons to do it, but you’ve never seen a case where it’s worth the cost in the long term. Eventually with experience (and several different contexts), you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
Maybe this doesn’t actually apply to git merges, but I imagine that there are certain things that eventually emerge as having extraordinarily unfavorable trade-off ratios.
It’s hard for me to think of anything off the top of my head, but one example could be using global scope for all of your variables. Sure, it’s a small app now, but do you really want to rewrite everything later when it’s impossible to understand? Of course there are (tiny) benefits to building an app with all global variables, but it’s hard to imagine that is ever a worthwhile trade-off, and I think it’s fair to build a strong opinion that you should use (at least some) local scope.
> you think the costs of squashing commits is so high that no reason to do it is worth the trade-off.
I think a "measured" approach here would be to say that the evidence required to convince you that this would be a good idea raises which each new domain in which you see it fail. It's not to say that you cannot be convinced; but it's to say that the burden of proof is heavy.
I think it often is the "multiplication" of severity and frequency. Once burned badly enough gives a lot of weight to your preference, even though it is not what you typically associate with the word "measure".
