On Tue, Feb 12, 2013 at 12:28:53PM +0100, Michael J Gruber wrote:

> I'm not sure providers like GitHub would fancy an interface which allows
> the programmatic creation of repos (giving a new meaning to "fork
> bomb"). But I bet you know better ;-)

You can already do that:


We rate-limit API requests, and I imagine we might do something similar
with create-over-git. But that is exactly the kind of implementation
detail that can go into a custom create-repo script.

> An alternative would be to teach git (the client) about repo types and
> how to create them. After all, a repo URL "ssh://host/path" gives a
> clear indication that "ssh host git init path" will create a repo.

But that's the point of a microformat. It _doesn't_ always work, because
the server may not allow arbitrary commands, or may have special
requirements on top of the "init". You can make the microformat be "git
init path", and servers can intercept calls to "git init" and translate
them into custom magic. But I think the world is a little simpler if we
define a new service type (alongside git-upload-pack, git-receive-pack,
etc), and let clients request it. Then it's clear what the client is
trying to do, it's easy for servers to hook into it, we can request it
over http, etc. And it can be extended over time to take more fields
(like repo description, etc).

I'm really not suggesting anything drastic. The wrapper case for ssh
would be as simple as a 3-line shell script which calls "git init" under
the hood, but it provides one level of indirection that makes
replacing/hooking it much simpler for servers. So the parts that are in
stock git would not be much work (most of the work would be on _calling_
it, but that is the same for adding a call to "git init").

I think the main reason the idea hasn't gone anywhere is that nobody
really cares _that_ much. People just don't create repositories that
often. I feel like this is one of those topics that comes up once a
year, and then nothing happens on it, because people just make their
repo manually and then stop caring about it.

Just my two cents, of course. :)

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to