git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Pushing a git repository to a new server

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Feb 13, 2013, 08:08 UTC
Message-ID
<511B4A04.1000104@drmicha.warpmail.net>
In-Reply-To
<20130212204210.GA25330@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 12.02.2013 21:42:
Show 9 quoted lines
> 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:
> 
>   http://developer.github.com/v3/repos/#create
Nice.
I knew you knew ;)
Show 33 quoted lines
> 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. :)

Most repos are probably created by a local "git init" or "git clone", or by clicking a button on a provider's web interface. The need for git-create-repo seems to be restricted to:

- "command line folks" who use a provider for it's hosting service and
don't fancy a web interface for repo creation
- noobs who need to get their head wrapped around local, remote,
push/pull 'n' stuff...

For the server side git-create-repo to take off we would probably need two things (besides the client support):

- Implement and ship a git-create-repo which makes this work for git
over ssh seamlessly. (Will take some to trickle down to servers in the
wild.)
- Get a large provider to offer this.

Gitosis/Gitolite are probably to follow easily. I'm beginning to like idea ;)

Michael
Previous: Jeff King
Message 10 of 10 in “Pushing a git repository to a new server”
  1. Ethan ReesorFeb 10, 2013
  2. Konstantin KhomoutovFeb 11, 2013
  3. Ethan ReesorFeb 11, 2013
  4. Konstantin KhomoutovFeb 11, 2013
  5. Ethan ReesorFeb 11, 2013
  6. Jeff KingFeb 11, 2013
  7. Ethan ReesorFeb 11, 2013
  8. Michael J GruberFeb 12, 2013
  9. Jeff KingFeb 12, 2013
  10. Michael J GruberFeb 13, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.