On Tuesday, 28 February 2017 at 14:52:36 UTC, Andrei Alexandrescu
wrote:
Thanks. I'd replace "changes should be split into as many
commits as is reasonable" with "changes should be split into as
many pull requests as is reasonable", which is a natural
consequence of "most pull requests should consist of one commit
upon merging". (Of course there may be several commits during
PR review.)
Well... not always. For example, introducing a private function
that is not called from anywhere is something that doesn't really
make sense as a pull request of its own, but does make sense as a
separate commit.
One vs. several commits per merged pull request is a matter in
which reasonable people may disagree, and we can't do both
ways. The Foundation fosters that github pull requests are
squashed upon merging, with exceptions that need to be
justified.
Sorry, but I don't think that's reasonable at all.
I have seen no arguments to support this way of doing things,
only downsides. Established major projects seem to agree.
As far as I can see, this is not about a subjective point
regarding which reasonable people may disagree. It seems to be a
poorly justified mandate, that's all.
As I've mentioned previously, you will need to provide some
arguments which would outweigh those supporting the opposite
position.
The Foundation fosters
IMHO, this phrase does not belong in technical discussions.
