Suggestion: Consider Squash and Merge for Cleaner Commit History

[Dr-Blank]

Dear Maintainers,

I'm a new contributor to this project and I've noticed that the commit history can sometimes be a bit difficult to follow. I wanted to suggest considering the use of a "Squash and Merge" strategy when accepting pull requests. I believe this could help make the commit history cleaner and more readable. Here are some reasons why squashing might be beneficial:

1. Simplicity: Squashing condenses all the changes into a single commit, which could make it easier to understand the changes that were introduced with each pull request.
2. Clean History: It might help reduce noise in the commit history by removing unnecessary "work-in-progress" commits.
3. Easier Reverts: If something goes wrong, it could be easier to revert a single commit than to have to find and revert a series of related commits.
4. Better Blame: When debugging, it might be easier to find the pull request that introduced an issue with git blame because each commit corresponds to a complete feature or bug fix.

I understand that squashing can obscure some details of the development process, but I thought the benefits of a clean, understandable commit history might be worth considering. The detailed changes can still be viewed in the closed pull request if needed.

I would appreciate any feedback or thoughts on this suggestion.

Thank you for your time and consideration.

[Serene-Arc]

Hi, I'm one of the maintainers for beets. I'm against this. There are a lot of benefits to squashing, but in the end it's about removing information about the development process and for me, that's a non-starter. GitHub is not git; information stored in GitHub PRs are not the same as the information in the actual commit process.

Part of the reason, to me, that git has been so successful and become standard is that everyone with the repo has everything related to it, at least in terms of commit. You can follow the additions, most of the reasoning, and construct a timeline of changes. Squashing just makes that harder.

With a project this large, many PRs have a large number of changes and consist of several different commits. Squashing them makes it harder to debug and assess them, not easier. It's not easier to find the PR associated with a single squash commit than a merge commit, and it's harder to see how the changes and implementation of feedback have influenced the final project.

If nothing else, there are many programs that make it easier to track git history and all of the splits and merges into graph form. Reverting a PR in several commits is just as easy as doing a single squash commit if you know what you're doing, and indeed it is much, much, much easier to do a partial reversion when the troublesome change is in a separate commit, which we encourage. The aim of the git history is not to provide a summary of the changes introduced with each PR; that's the job of the changelog, not a commit message.

Sorry, but it's a no for me.