The case for small diffs in Pull Requests

[Steven Schveighoffer via Digitalmars-d]

On 7/20/16 1:09 PM, Vladimir Panteleev wrote:
> On Tuesday, 19 July 2016 at 06:29:05 UTC, Jacob Carlborg wrote:
>> On 2016-07-19 00:30, Walter Bright wrote:
>>> https://medium.com/@kurtisnusbaum/large-diffs-are-hurting-your-ability-to-ship-e0b2b41e8acf#.h3eo1yvqv
>>>
>>>
>>>
>>> I've been advocating for a while now that PRs should be small,
>>> incremental, encapsulated and focused. This has not been without
>>> controversy. I hope the referenced article is a bit more eloquent and
>>> convincing than I have been.
>>
>> I fully agree, the problem is if unfinished features are merged to
>> master, which has happened quite a lot in D. Have you read the
>> solution, linked at the bottom? [1]. As far as I can remember, I have
>> not seen this used in the D projects at all.
>>
>> [1]
>> http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/
>>
>
> Requiring that all contributors do this would kill D development.
>
> This method strikes me as nothing but a very ugly work-around for GitHub
> not having good facilities of reviewing PRs commit-by-commit.

Huh? This works fine. I just used it as an advantage for reviewing: 
https://github.com/dlang/druntime/pull/1602

> There is another, much simpler and IMO better way:
>
[snip]

These are all good guidelines!

I'm not a big fan of rebasing unless you are testing things out. For 
example, if you introduce a bug in your PR and then fix it, there's no 
reason to keep that bug somewhere in history.

The idea of squashing commits just because they are too many, I don't 
see the point.

-Steve