Subject: Re: Pushing a git repository to a new server

From: Michael J Gruber <[email-masked]>
Date: Tue, 12 Feb 2013 12:28:53 +0100

Jeff King venit, vidit, dixit 11.02.2013 17:27:
> On Mon, Feb 11, 2013 at 02:57:51AM -0500, Ethan Reesor wrote:
> 
>> On Mon, Feb 11, 2013 at 2:50 AM, Konstantin Khomoutov
>> <[email-masked]> wrote:
>>> What's wrong with
>>> $ ssh myuser@remotehost 'mkdir /path/to/MyRepo.git; cd $_; git init --bare'
>>> $ git push --all git@remotehost:MyOtherRepo.git
>>> ?
>>
>> Nothing, I just wanted to make myself a command to do that for me.
> 
> We talked about this a long time ago. One problem is that it's
> inherently unportable, as the procedure to make a repo is potentially
> different on every server (and certainly that is the case between a
> regular user running stock git and something like GitHub or Google Code;
> I imagine even gitolite has some special procedures for creating repos,
> too).
> 
> One proposal made in the previous discussion was to define a microformat
> for repository administration commands. So that you could connect and
> say "git admin-create-repo /path/to/MyRepo.git", and the server-provided
> admin-create-repo command would take care of the details. Then stock git
> could forward it to "git init --bare", GitHub could do the same and
> create the necessary database records, etc.
>
> And once that standardized method was in place, it would be easy to add
> a "--create" option to "git push" to request an "admin-create-repo"
> before pushing.
> 
> I still think that's a reasonable way forward, but nobody was interested
> enough to start writing code for it.
> 
> -Peff
> 

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 ;-)

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. I'm
wondering whether it's more likely to convince providers (the server
side) or more is gained by covering the simpler cases client-side (our
side).

Michael