Even with #781300: option to lock project short name we're going to need something that notices when new project nodes exist on d.o (perhaps the maintainer has to request a repo via the UI somehow) that can turn around and create the appropriate Git repository on git.d.o.
It's possible that gitolite solves this for us, but it's also possible we won't be using gitolite depending on what happens over at #714034: Determine the access control solution for git. ;)
If this isn't solved automatically, I'd strongly favor an architecture that avoids giving httpd write access to Git. ;) For example, there's a dirty bit on project nodes that's set when a project needs a git repo for itself. Something on git.d.o queries for projects with the dirty bit set, creates the repos, and clears the dirty bit. Or whatever.
Just capturing an issue for this since Sam and I were discussing this, especially as relates to #851208: Create a d.o clone for Git development.
Comments
Comment #1
damien tournoud commentedGitolite or not, there is probably no explicit creation required here, as Git will initialize the repository on the first push.
But of course, we need to set up the access control rules needed when a new project is added.
Comment #2
marvil07 commentedI tried some simple examples to figure if git actually _create repo_ on push, and I it seems that it can not.
In the other side, like mentioned before either gitosis or gitolite do the work right, so definitely there should be a way to do this.
Comment #3
sdboyer commentedTalked with nnewton, and he's a fan of a job queuing system to drive this process. We're currently leaning towards beanstalk.
Comment #4
sdboyer commentedComment #5
webchickImplementation of this is dependent on #893108: Decide on job queueing system.
Comment #6
marvil07 commentedDuplicating this in favour of #910562: Implement a git-shell wrapper with python-twisted since IIRC I have seen it creating git repos in the sprint 4 demo.