On Thursday, 21 July 2016 at 06:04:24 UTC, default0 wrote:
> On Thursday, 21 July 2016 at 03:30:34 UTC, Walter Bright wrote:
>> I've looked at many PRs that consisted of multiple commits.
>>
>> The trouble with them is:
>>
>> 1. they often have nothing in particular to do with each other
>>
>> 2. I may want to pull a subset of the commits, but the only option I have is all or nothing
>
> As far as I'm aware git offers the option of cherry picking commits. It will not mark the PR as merged or generally not be what you are looking for, but maybe it's a usable workaround :)

Git does, but Github does not.

D uses a bot [0] to do the merging. Afaik the process is that an authorized person (Walter, Andrei, etc) comment with "Auto-merge toggled on", then the bot toggles the merge after it ensures that tests pass.

In theory, the bot could be extended to merge only certain commits and exclude others. That might solve (2), but it muddles the review process.

(1) is not to be solved. If commits have nothing to do with each other then the should be in separate pull requests.

[0] https://github.com/braddr/d-tester

On 7/21/16 3:10 AM, qznc wrote:

> D uses a bot [0] to do the merging. Afaik the process is that an
> authorized person (Walter, Andrei, etc) comment with "Auto-merge toggled
> on", then the bot toggles the merge after it ensures that tests pass.

Just FYI, there is a toggle on the auto-tester UI that adds the comment, and then merges using that user's id.

-Steve

On Monday, 18 July 2016 at 22:30:56 UTC, 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.

In my experience, the number of commits in a pull request is irrelevant. You can always merge the entire pull request with `git merge --squash` instead, and if you have the luxury of merging via GitHub as I do in my day job, you can even do that via GitHub now.

What is definitely relevant is the lines of code. Once a pull request becomes too large, the probability that it will be merged decreases. At least that has been my experience. I agree that incremental changes are much more likely too succeed than large comprehensive changes. However, exceptions do have to be made, because there are some tasks which just cannot be completely incrementally, though they may be rare.

Just my two cents.

On 7/21/2016 11:57 AM, w0rp wrote:
> I agree that incremental changes are much more likely too
> succeed than large comprehensive changes. However, exceptions do have to be
> made, because there are some tasks which just cannot be completely
> incrementally, though they may be rare.

There are always exceptions. Any rule needs to be leavened with good judgement, not thoughtlessly followed.