[llvm-dev] RFC: Move the test-suite LLVM project to GitHub?
Joachim Durchholz via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 25 04:46:10 PST 2016
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
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.
More information about the llvm-dev