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)!
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.
@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 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.
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.
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.
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!