4 ms·
When working to maintain a large open source project with hundreds of monthly contributors, in which those forks/branches contain a significant number of commit
by andrew_ 6y ago
When working to maintain a large open source project with hundreds of monthly contributors, in which those forks/branches contain a significant number of commits themselves, squashing is preferable when merging to master. We only really care about the end result of a Pull Request (in the context of Github), and we use that to assemble changelogs and release notes.
There isn't a one-size-fits-all doctrine here. It's subjective based on the goals, size, contributor base, etc of an individual project and the leadership of the project.
- MonadIsPronad 6y ago> We only really care about the end result of a Pull Request (in the context of Github) Hmm, I'm not sure that's true. Imagine if this excellent commit got squashed, there'd be something really lost: https://dhwthompson.com/2019/my-favourite-git-commit https://dhwthompson.com/2019/my-favourite-git-commit
- imtringued 6y agoSquashed into what? If someone submits a PR with only one commit then squashing does nothing.
- deleted 6y ago[deleted]
- kevinherron 6y agoYes, and that excellent commit would make an excellent PR all on its own. It’s entirely self-contained and should not be lumped in with some other change, so there is no reason it would be squashed in the first place.
- mahkoh 6y ago>We only really care about the end result of a Pull Request The thing we care about is a bisectable repository where each commit does one thing only and that thing is described in the commit message. Squashing makes this impossible unless the pull request could have been written as a single patch without violating the above rules. Hopefully this is what the OP means with his first point. PRs that mix fixes to existing code and new features in a single commit will most likely be rejected.