On Wed, Jul 22, 2015 at 2:48 PM, Ryan Lane <rlane32@gmail.com> wrote:

Some of the largest open source projects around are on github:

https://github.com/saltstack/salt/pulse/monthly

https://github.com/docker/docker/pulse/monthly

Which does not necessarily mean it does not suck for them. Some large projects are still on Sourceforge. Some large projects still use SVN. etc. Change is hard.

> * poor repository management (fun fact: GitHub does not even log force

> pushes, much less provides any ability to undo them)

You can have force push to master disabled. Also their fork model (which I
dislike for other reasons) means you can limit access to the main fork to a
small set of people and require all pull requests to come from branches of
forks. It's the default model for basically every public github project.

So force pushes can only obliterate feature branches, version branches and whatnot.

(GitHub actually developed sane management of force pushes but only included into their enterprise version. I guess that does not quite qualify as doing evil things but still is unpleasant.)

> * noisy commit histories due to poor support of amend-based workflows, and
> also because poor message generation of the editing interface (Linus wrote
> a famous rant
> <https://github.com/torvalds/linux/pull/17#issuecomment-5654674> on that)

You can manage that yourself through rebasing of PRs. That's completely
based on your workflow and what you require of contributors (or how you do
your merges).

GitHub's PR interface sucks with a rebase-heavy workflow. There is no indication that a commit is a rebased version of a former commit; former commits disappear without trace; inline comments to former commits become unintelligible. And you need force push to do it which has potentially disastrous effects on GitHub.

> * no way to mark patches which depend on each other

Sure you can. All PRs are also issues and can be referenced by issue
number. If you mention the issue in a comment it adds a reference for you.

Which will not stop the CI infrastructure from testing your patch without pulling in its dependencies, not will it stop a careless reviewer from merging it without the dependencies.

> * diff view works poorly for large patches

It's way better than gerrit. May not be better than phabricator, though.

Here is a patch I made a few days ago: https://gerrit.wikimedia.org/r/#/c/225827/

Here is the same patch in GitHub: https://github.com/wikimedia/operations-software-sentry/commit/ae8bc0fe9adad6f09f3da72a70e888798ff5a22e

(Warning: might crash your browser.)

> * CR interface works poorly for large patches (no way to write draft
> comments so you need to do two passes; discussions can be marked as
> obsolete by unrelated code changes in their vicinity)

You can delete and edit your comments. Draft comments in gerrit are an
anti-pattern IMO.

Deleting or reworking comments after email notifications have already been sent out with them is much more of an antipattern.

Anyway, I did not intend to start a GitHub-vs-Gerrit deathmatch, nor to criticize the iOS team's decision (at their team size GitHub makes perfect sense IMO), just answer Petr's question about why don't we all just move to GitHub.