1. 3

  2. 1

    I’ve just discovered a scenario where squashed commits is really nice, _even for single-commit PRs.

    We put restrictions on master so that every PR has to be up-to-date with master in order to be pulled. However, if you make two separate PRs at the same time one of them will have to be merged before the other and then you need to update B to master before it is up to date. Unless there were any conflicts this can be done by simply clicking a button in the GitHub UI, but then you end up with a merge commit. Sometimes you have to do this several times. Then, with the old style merge, you end up having not only your one commit + a merge commit, but potentially several ‘merged master into feature branch’ commits too. By squashing the merge, you end up with a clean history without those extra merge commits.

    1. 1

      Despite being published on the 1st of April I did just check the settings of one of my repositories and it has the ‘Allows squash merging’ option described in the post. However, it doesn’t appear to do anything: I just created a multi-commit PR to test and I don’t get the “confirm squash and merge” option.

      1. 1

        I like history.

        1. 5

          I like history too. Squashing makes perfect sense, to me, if you have a PR where one commit adds a feature, and the next just fixes a typo in a comment. Or adds a note to the README about the feature. Nobody, I think, is arguing that pulls should always be squashed—but it would be nice to have the option to where it makes sense to the maintainer.

          1. 6

            I’d love to live in a world where everyone understands git / the importance of a good history well, but we don’t.

            I’m glad it’s now easier to accept contributions from people who don’t write a tidy history.