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

[Joachim Durchholz via llvm-dev]

Am 25.02.2016 um 12:33 schrieb Renato Golin via llvm-dev:
> Kristof, Chandler,
>
> I think most of the responses seem favourable of the move, the
> concerns being which Git repo we'll use (GitHub, GitLab, BitBucket),
> but they're essentially identical on the git side.

I'm repeating myself but not they are not identical on the git side. Not 
for people without push access to the main repo anyway.

There's the GitHub model where you need to set up a remote repository, 
and the non-GitHub model where you push to a branch within the master 
repository. Obviously, the non-GitHub model needs to protect people from 
messing with other people's branches, particularly not with the master 
branch, but that's pretty much a solved problem.

> Infrastructure decisions will need to be taken into account, but that
> doesn't interfere with the "how we commit" discussion in any way.

Regular committers with write access to repositories have a different 
workflow than occasional contributors who send patches or pull requests.
You need to consider all values of "we" that you are interested in 
getting work from.

> I believe all those services use something similar to git-new-workdir,
> so even if we have 100 forks of the test-suite, we won't have 100 x
> 1GB of used space.

GitHub explicitly confirms that "forking" (remotely cloning) a repo does 
not copy the data.

 > But if we move into a "less owners" scenario, we
> will penalise them with pull-requests all the time.

What workflow are you comparing this to, if a pull request is a penalty?

> 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.

This depends very much on repo configuration.
For git itself, write access is roughly equivalent to svn administrator 
access. However, all public-writable repos have an authorization layer 
that prevents history from ever being wiped. Take a look at gitolite, 
that's the standard tool for managing such a layer.

> If anyone with more git experience than me can come up with a safe way
> to have 100s of committers pushing to master, I'd be happy to know.

Nobody is allowing 100s of committers to push to master, that would be 
silly.
You push to either a remote clone (GitHub) or a remote branch (GitLab), 
and the master's owner does the merge. These are essentially an 
alternative to sending patches by mail, with the added bonus that the 
Git* websites give you a forum website where you can open threads on 
individual lines of code, including an email gateway.

Regards,
Jo