|
|
|
|
|
|
by thunky
1323 days ago
|
|
|
The extra discipline I'm talking about has to do with curating the commits in order to make them meaningful. Here's an example of this from the wild: https://github.com/BurntSushi/ripgrep/pull/350#issuecomment-... BurntSushi (the project maintainer) didn't care about the story the commits told, he cared about the entirety of the changes being made to the repo (at the PR level). > What's lost is the ability to make code contributions of related changes together in a PR You're considering each minor commit to be an independent code contribution. BurntSushi instead considered the PR to be the code contribution. The code changes are the same either way you look at it, and there is a single PR in both cases, so it's a matter of choosing your perspective. |
|
|
* Most PRs that come in do indeed get squashed merged, but because of a few reasons. Sometimes it's because the PR is really just one logical change and really should just be one commit. Sometimes it's because the commit messages are not written in a way that I like, and so I do a squash-merge so I can either edit or re-write the commit messages provided by the author.
* Sometimes I do a "rebase and merge" if the commit breakdown is good and so are the messages. It's somewhat rare, but some contributors get it right. I'm fine with a single PR containing multiple commits, but the common case is indeed "one PR = one commit."
* I don't usually levy this criticism because I think it's low-brow, but the OP here---"git commit messages are useless"---is pretty egregious clickbait. Halfway into the article, the OP acknowledges that they aren't useless, but just useless in the context of a PR workflow. Which... I don't also 100% agree with, but is usually true for very small changes. What an annoying submission.