But what you care about when you write code isn't half as relevant as what you care about when it's being used.
A squash commit removes any provenance tracking. Outside of the author of the merge commit, you do not have any record of who wrote which line of code, which means that all of the authors have effectively given up their authorship and any rights associated with them.
Germany - and some other countries - have a strange view of copyright in that here there exists also Urheberrecht 2/
... which is something you *cannot* give away. The moment you put your name to something, you have that right to it. You can still give away copyright and all other rights associated with that, but Urheberrecht remains, and with it some rights for the authors.
The details of that do not matter too much in this context, except to give an example that provenance matters; leave your name off the record, and your rights are gone as well.
In your open source project, it means that the ... 3/
... people who perform the squash merges effectively become the authors on record of the entire code base, and can therefore change the license as they please, without asking for your permission. You may not be happy with that.
For commercial software, provenance tracking is a big part of IP management, and often a legal requirement - it really depends on the industry it's used it. Squash merges can make the legal track record says something entirely different from reality, and that ... 4/
... also affects how reliable IP transfer is.
Imagine you think you know who wrote your IP, you think you own it, and you sell it, and everyone's happy. And then sometime later someone turns up who happens to have kept a copy of the branch to be merged, and they can prove that they own part of the IP.
If you're a smart buyer of IP, you will make the seller liable for such eventualities in your sales contract.
At businesses, squash merges are bad practice for IP reasons. The open source ... 5/
... example isn't all that different, really, except that the collateral damage is resilience in the ability to enforce copyleft, etc.
If that's the kind of license you're using, why sabotage yourself?
If it's not - as in very permissive licenses or public domain - okay, whatever, it probably makes no difference.
@jens I don't agree that they are stupid and should go away period, but I think we can agree that they have a few limited and well defined use-cases but should be used with some thought. Perhaps revisioning software implementing it should reject squashes if commits have different authors and require a --force?
@espen I'm not sure what the benefits are.
I mean, as I wrote in the first post, the only reasonable rationale I've heard is not to clutter the main branch.
I also see developers literally (!) using the CI setup to syntax check their code - one-line commits being made without even understanding whether the code is correct.
If this is the coding practice we're talking about, squash merges may seem essential.
But the simple fix would be to make sure that you commit reasonable change sets.
@espen My point being is that it's very hard to state without further context in the absolute that squash commits or any other practice are good or bad.
My very broad opinion is, though, that tool uses that introduce new problems are something that should generally be avoided, and lead to investigation of this wider context. What caused you to use squash merges in the first place?
In the cases where I have been asked to use them, the reason tended to be a bike shed colour. YMMV for sure!
"My very broad opinion is, though, that tool uses that introduce new problems are something that should generally be avoided…"
Which is why I use computers as little as I can possibly manage!
@jens Well, you are right. avoid clutter would be the main point of doing it at all. The limited usecase I am talking about is for instance if you make a commit implementing a certain feature, then makes several more commits because you 1) forgot to fomat the code per project standard, 2) made some small but annoying type errors and 3) Decided that the function could be better documented and added a few more comments. In this case, assuming all commits were from the same author, I'd have no issues combining them to one commit before merging. But, as you say, the only reason to not include all the "fluff" would be to avoid clutter. History is good but not ALL history is equably valuable.
@jens I guess that would be up to individual projects to figure out the level of detail they want. Personally I tend to view commits as a series of steps on how you get from A to B, the travel analogy would be
"Step 1: take a left" and "Step 2: Straight for 3 km", etc. As such, very few commits where you arrive instantly, one commit with all the work done, is not very useful. But I argue that neither is, to continue the travel analogy, steps like "Step 8: Took a wrong turn and got lost for a while." and "Step 17: Stopped for coffee." There is no harm to include them, but they don't bring more clarity either, probably just serving as a distraction and is something I would personally want to remove.
@espen here it's I who disagree.
I've made a bunch of commits like you describe, and every time I'm a bit annoyed at their uselessness. Better to squash them, right?
Well, in the repo that I have in mind here, I've always made them in the same situation. I'm not sure I'd be so annoyed with them if I'd squashed them all the time.
But since I haven't and am, I understand that this part of the development process is a good target for improvement.
In other examples I can think of, ...
@espen ... innocent looking commits produced bugs (TL;DR - writable data segments are traps), and isolating small changes long after the fact helped find the issue.
I'm not sure that every silly commit has value, of course. But since a clean history is a rather arbitrary metric to look at, and I've had plenty of experiences like those, I'm inclined to prefer a bit of clutter over losing history and context.
It's okay if that doesn't convince you for what it's worth. It's been good to...
@espen ... read your disagreement also to clarify to myself why I value every commit as is independently of the IP management issue.
@jens also, when you digitally sign your commits, 'squash and merge' will replace the signatures of the original author with a signature of the squasher (if even that).
In some cases, esp. where there is a clear 'primary author' who can be the author of the resulting commit, I'm kinda fine with squashing though.
A private instance for the Finkhäuser family.