Multi-commit PRs vs. multiple single-commit PRs

[deadalnix via Digitalmars-d]

On Wednesday, 22 March 2017 at 09:02:24 UTC, Vladimir Panteleev 
wrote:
> On Tuesday, 21 March 2017 at 18:07:57 UTC, deadalnix wrote:
>> Large companies such as Google or Facebook
>
> A blind appeal to authority is fallacious, but it's still 
> worthwhile to see what others are doing. I think it's important 
> to look at projects that are similar to our own, so I looked at 
> what other programming language implementations do.
>

The good new is, you provided much more authorities to confirm my 
claim, so is it so blind ?

> - Go is developed using Google's source code infrastructure, 
> and code reviews happen using Gerrit. On Gerrit, every commit 
> is reviewed separately (as I've been advocating). Furthermore, 
> if you push multiple commits to Gerrit, this automatically 
> creates one review page per commit, and marks them as 
> inter-dependent in the commit order. This is an awesome 
> approach, and I wish GitHub made this workflow more practical. 
> Importantly, Gerrit does not squash commits - you are expected 
> to squash fixup commits yourself.
>

So Go use squash.

> - Rust uses GitHub, and all merges seem to be done by a bot. We 
> are heading in that direction too. The bot uses regular merges 
> and does not squash commits or rebase them onto master.
>

So that's 1.

> - Python: I looked at the CPython repository on GitHub. They 
> seem to be using squashing exclusively, and only using branches 
> for version maintenance. However, when I tried to find how they 
> would deal with a contribution that would be desirable to be 
> split into several PRs/commits, I couldn't find one on the 
> first 5 pages of merged PRs. I guess the project is in the 
> stage of mostly minor bugfixes only - we're certainly not there 
> yet.
>
>   Curiously, submitters are expected to resubmit the same PR 
> themselves against every maintenance branch, e.g. here is the 
> same PR submitted 4 times, to different branches:
>
>   - https://github.com/python/cpython/pull/629
>   - https://github.com/python/cpython/pull/633
>   - https://github.com/python/cpython/pull/634
>   - https://github.com/python/cpython/pull/635
>

So they use squash.

> - Ruby uses Subversion, a GitHub mirror, and a bot which 
> synchronizes between the two. I don't think there's anything we 
> can learn from here.
>

So they use squash (that's the only thing svn knows how to do).

> - OCaml uses GitHub PRs and regular git merges.
>

That's 2.

> - Clang and GHC use Phabricator. I'm not too familiar with it, 
> but I understand it's not too different from Gerrit: it creates 
> one review per commit, and you can push multiple commits at 
> once which will do the right thing.
>

Phabricator can be configured to do many things, pretty much like 
gerrit, but in the case of clang and LLVM, they use squash.

> To sum it up, I don't think we're doing anything too weird. 
> Though it would be nice if GitHub's UI were to improve to 
> better handle this workflow, I don't think it makes sense to 
> force submitters to go through the busywork of creating one PR 
> per commit for many cases.

4 out of your 6 examples use squash.