[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?

[Tony Kelman via llvm-dev]

Mehdi Amini via llvm-dev <llvm-dev <at> lists.llvm.org> writes:

> > This is a little more complex. SVN is very conservative on history,
> > and that saves us from destroying the origin. Git, on the other hand,
> > allows anyone with write access to completely wipe out the repo. I
> > don't think anyone would want to, but accidents do happen in git.
> 
> This is why git has "hooks": for example
https://gist.github.com/stefansundin/d465f1e331fc5c632088
> 
> You can prevent from rewriting the history on the server side, which
eliminate risk of "accidents". (You
> can have a whitelist of people allowed to rewrite the history...).

One downside of hooks is that you're relying on everyone who has commit
access to manually set them up on every machine they might commit from.
On the server side, GitHub has a relatively recent feature called
protected branches that you can enable
(https://github.com/blog/2051-protected-branches-and-required-status-checks)
to prevent force pushing
to important permanent branches like master or releases. Force pushing
to temporary personal branches is usually fine, but it's cleaner to
store personal branches within your personal fork rather than inside
the official main repo anyway.

They also have an additional option on top of the protected branch
feature that only allows pull requests to be merged if they've passed
certain status checks from external CI services like Travis CI, AppVeyor,
etc. It's also possible to make buildbot send status webhooks to github
for this, but this only helps if the buildbot is configured to do
pre-merge testing the way Rust does rather than post-commit testing
like LLVM's buildbots do now. I've found the required status checks
are picky about not accepting green statuses that were run against an
out-of-date merge commit, so the required status feature isn't really
suitable for a rapidly changing master from my experience the last time
I tried it.

-Tony