4 ms·

> 5. Squash Those Commits That's very odd advice, as the reverse actually should apply. Since (in GitHub) merging with squash costs just one click more to the

> 5. Squash Those Commits That's very odd advice, as the reverse actually should apply. Since (in GitHub) merging with squash costs just one click more to the maintainer, and one can't separate squashed commits, having separate commits should be the default behavior. I'd say that it's preferrable to squash a disorderly branch history, but then, it's about being orderly rather than squashing for its own sake.

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 ago
    Squashed into what? If someone submits a PR with only one commit then squashing does nothing.
  - deleted 6y ago
    [deleted]
  - kevinherron 6y ago
    Yes, 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.
fuzzy2 6y ago
I think that should mostly be up to the maintainer. It’s easy to complete pull requests in whatever desired way: Rebase, Merge, Squash, …
armada651 6y ago
> That said, there are no projects that require not squashing commits. This isn't true either. I've worked on projects before where if you have a PR that makes changes all across the codebase in one commit, then you will get asked to split that commit up.
pizza234 6y ago
I'll clarify what I meant: 1. if submitters squash their commits into one by default, it's hard to split, if the maintainer wants; 2. if they send separate commits by default, it takes only one extra click to the maintainer to squash them, if they want. So, the second case is more flexible.

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 ago
  Squashed into what? If someone submits a PR with only one commit then squashing does nothing.
- deleted 6y ago
  [deleted]
- kevinherron 6y ago
  Yes, 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.

fuzzy2 6y ago

I think that should mostly be up to the maintainer. It’s easy to complete pull requests in whatever desired way: Rebase, Merge, Squash, …

armada651 6y ago

> That said, there are no projects that require not squashing commits. This isn't true either. I've worked on projects before where if you have a PR that makes changes all across the codebase in one commit, then you will get asked to split that commit up.

pizza234 6y ago

I'll clarify what I meant: 1. if submitters squash their commits into one by default, it's hard to split, if the maintainer wants; 2. if they send separate commits by default, it takes only one extra click to the maintainer to squash them, if they want. So, the second case is more flexible.