On Wed, Jul 22, 2015 at 2:48 PM, Ryan Lane <rlane32(a)gmail.com> wrote:
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/ae8bc0fe9ada…
(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.