Am I the only one who thinks this is fine? If you have reasonably scoped PRs I don't find the rewriting history thing to be a problem - your feature appears in main as a single commit. I think if the squash makes it unclear what's going on the change shouldn't have been a single PR

@brokenintuition yes you're the only one, because it is absolutely not okay to break GPG signatures, tracability and kill all effort the author has put into crafting the commit messages (and more, read the thread)!

@musicmatze @brokenintuition AFAIK the commit messages aren't lost, they're all joined into a single one. If the author chooses to craft a descriptive one, it's kept.

We're talking GitHub here so blame takes you straight to the PR where individual commits are separated and visible.

YMMV but in projects with several PRs merged daily seeing the high level summary of changes in linear history is better experience than going through 100s of changes such as addressing linter warnings etc.

@musicmatze @brokenintuition as an example of well maintained history without its byproducts polluting the public timeline I like to showcase - I guess my point is there's always two sides of the coin 🤷‍♂️

@hq1 @brokenintuition my point being that git makes it easy for the maintainer. Squashing breaks everything that is in place for making things easy for the maintainer, plus it also makes it difficult for later contributors to comprehend why a certain change was done. Should've have been "invented".

But of course that's just my take on the subject and we all are allowed to have our own opinions! 🎉

I chose to not contribute to projects that squash my changes. Just a waste of time for me.

@hq1 @brokenintuition "should've never been invented" of course. I edited that message too much :sad_but_cool:

@hq1 @brokenintuition Yes, the commit messages are joined. That renders them completely useless, because the commit shows a diff combined of N commits and the message shows a list of N messages. Possibility to associate complete destroyed.

The author can NOT craft descriptive messages, the maintainer/person that does the merge can.

@hq1 @brokenintuition
Blame cannot take me anywhere when I'm offline. And even if I'm online it is way more effort than just _reading_ the message.

Where in the world is linear history a better xp than having the actual change described by the actual author of the change?

@musicmatze @brokenintuition

It's a fair point about offline work.

> Where in the world

I prefer to read top to bottom high level summaries. I almost never care about small atomic changes.
In many teams I've worked with that was the consensus 🤷‍♂️. You can go all jihad about it but not all changes are considered meaningful and a lot depends on your workflow and discipline shared across the organisation and I guess the specific characteristics of the software you're building.

@hq1 @brokenintuition about that discipline thing: Yes. I always talk open source, so I assume no discipline at all!

I have a funny case at hand, actually. I've been working with someone on a feature for ~6 months now on a feature branch. Easily >600 commits, merging forth and back, reverting changes and documenting change very carefully.

If that gets squashed, I will rage-quit. And I told them. That'd result in >6kLOC "commit message" with >15kloc changes. Unusable AF.

@musicmatze @brokenintuition I remember reading a study saying that reviewers can't really comprehend changes as big as 15k LoC so there is a chance no one will read it thoroughly anyway 😜

@hq1 @brokenintuition yep. That's a whole other story, why it isn't merged yet... but I guarantee you: there were plenty of options early on. 😉

@hq1 @brokenintuition also, luckily, the part that really has to be reviewed is only about 3 to 4kloc, not all of it.

@hq1 @brokenintuition I'd rather not yet share this, sorry. It is OSS, so I can share this at some point, but as the project is currently in a somewhat "hot phase" organizational-wise, I'd rather not share right now, I hope you understand.

I might in a few weeks though.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!