Squash merges are a stupid idea, stop doing them.
Ok, so people do this because they don't want to "clutter" their main branch with a ton of commits when only the results matter. Right? I mean, that's the best rationale I've heard of so far.
But it's a real problem when it comes to IP management.
Maybe in your open source project, you don't care about IP. And you're free to choose a copyleft or permissive license, or even give the code to the public domain to express how little you care. 1/
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.
@Escobar If you go back to the OP, you'll see that I write about squash merges, not commits.
I'm also not a fan of squash commits for reasons I outlined elsewhere in this thread, but the real issue here are squash merges.
@Escobar I'm getting a lot of zen vibes from you, friend.
One of the issues with squash merging your own branch is that it also obliterates your work record and leaves the results only.
I can see two classes of issues there, one in a commercial setting and a larger one.
Let's start with the commercial setting. I wrote about IP management earlier; this issue is not specifically related to IP management, but it is related to the acquisition of IP and cost estimation related to it. 1/
@Escobar If I acquire IP, it's a fairly short-sighted view that, well, I'm only acquiring IP. Usually I also acquire - sort of by default - the user base, but I also receive all the problems associated with the business that surrounds it.
Squash commits or squash merges, it really doesn't matter here, obliterates the record of how much work went into the IP.
You might find that desirable; as a buyer, I do not. I would like to see what the work cost associated with the IP I acquire is. 2/
@Escobar Which means as a seller, well, it depends on your personality I guess. You may trick the buyer by obliterating this history, and stand to gain. Or your buyer is savvy enough and uses this as a reason to negotiate the price down. I really couldn't say.
But the argument *for* squashing in this context is really very similar to the argument for any kind of dishonesty: it's potentially beneficial, if you can get away with it.
This everyone has to decide for themselves.
@Escobar In the more general sense, obliterating the history of creation and just presenting the results isn't particularly healthy for society. In our case, for the development communities we participate in.
Because much like swimsuit magazine covers, it sets standards that are for most people impossible to achieve.
Sure. If I commit one flawless thing instead of 20 flawed ones, it'll make me look good. It also gives everyone else a false impression of what's actually required to ... 4/
@Escobar ... produce good code. And that's rarely perfection flowing forth from my mighty pen, but rather the ability to see my own work for its flaws, and take corrective measures.
It enables people commenting on whether the corrective measures were good for the problem at hand, or alternatives might have been better. I could go on.
What I'm describing here is transparency, and all the benefits that can follow from this.
I'm not sure how code occultism can be an improvement over that. /5
@Escobar You're describing what it does, not what it's needed for.
You imply a need in author's bad habits; those are not changed when there is tool support to lessen their impact.
So how is the feature helping address the bad habits?
@Escobar And yet you are arguing for tool support to deal with exactly this kind of peeve, while I do nothing of the kind.
I can see the zen vibes getting stronger.
@Escobar It is very difficult for me to misunderstand the meaning of my own thread, and my reasons for starting it, friend.
I have given you plenty of reasons for my thinking, and your response amounts to a pretty unfriendly "but I want it anyway for reasons I value more".
That's fine. You can have those reasons. You can value them more highly, too.
But you cannot insult me into thinking they're good. Please adjust your communication strategy accordingly.
@Escobar I'm trying to bring you back to a civil level of discourse, but I can see that failing badly. Your choice.
The purpose of git is revision control. It isn't editing a file. It isn't testing it for correctness. It isn't compiling, it isn't debugging, it isn't linting.
If sufficient of these other tools are used sufficiently, there remains very little need for adding squash support to revision control. You want it anyway.
Uncivilly, in the exact same kind of tone as you have used here:
@Escobar Your argument is that you want a screwdriver attachment to a hammer because there are people who don't use screwdrivers well.
You can argue that way, sure... just please do it elsewhere, it's a little tiresome.
A private instance for the Finkhäuser family.