Why not clone to a remote directory over SSH

It might be cool to enable cloning to a remote over ssh if the remote doesn't yet exist.

% git clone . machine:/path/to/new/repository

If you try this now it will clone the current working repository to a new directory called 'machine:'.

Carl

On Wed, Nov 23, 2005 at 02:16:01PM -0700, Carl Baldwin wrote:

I would like to see the same for http. There is limited support for managing a repository using http but without the ability to run tools like init-db/clone/update-server-info you still need shell access or some other workaround. I think it would be useful to allow someone to create, manage, and share a repository without any special intelligence on the server side.

Nick Hengeveld wrote:

You'll still need to install at least git-init-db and git-receive-pack (and git-merge, and...), even if they're run through commands from the web. That's pretty special intelligence.

You'd also have to add some logic to enter_repo() to make it find repositories without a HEAD correctly.

On Thu, Nov 24, 2005 at 12:15:02AM +0100, Andreas Ericsson wrote:

If the server is DAV-enabled, a local git-init-db could use HTTP to create an empty remote repository, and git-http-push can already send local changes including merges etc. to such a remote repository.

Want to host your project using GIT?  Just use your .Mac iDisk.

Hi,

On Wed, 23 Nov 2005, Nick Hengeveld wrote:

That would be cool! And git-clone could be patched to do just that.

BTW, is it possible to convince git-http-push to store packs on the server?

For that matter, is it possible to generate the file(s) needed for a dumb server on the client side?

Ciao, Dscho

On Thu, Nov 24, 2005 at 12:45:18AM +0100, Johannes Schindelin wrote:

Certainly, I'm not sure what conditions make sense for using packs though.

When pushing changes to the server, there's an advantage to using loose objects in that there is no way to resume a failed transfer. So if the network barfs 99% of the way through, you'll be much less annoyed if you need to retransmit the one object rather than a whole pack.

The same problem exists if you decide to pack loose objects on the server since the pack would have to be generated locally and then sent to the server. At least in this case, other remote clients would still be able to fetch loose objects while packs were in transit.

Which files are those? I've been working on a way to update info/refs and eventually objects/info/packs.

Hi,

On Wed, 23 Nov 2005, Nick Hengeveld wrote:

These I meant.

Ciao, Dscho

On Thu, Nov 24, 2005 at 11:36:58AM +0100, Johannes Schindelin wrote:

Yes - it should be straightforward to generate those files on the client side. A PROPFIND request for the remote directory with Depth: 1 will return a list of files in the directory, so refs and objects/packs can be crawled to generate the contents of the server info files. That's assuming that packs and tags are being pushed of course.

Come to think of it, PROPFIND is probably a more efficient way to check for the existence of an object in the remote repo as well. That would make it feasible to remove the --complete option and always verify the full history.

Carl Baldwin <cnb@fc.hp.com> writes:

I wonder if that is:

	$ ssh machine 'git clone '`hostname`:`pwd`' /path/to/new/repository'

Obviously you need a working git setup on the other end and probably need to be much more careful shell-quoting if your hostname and pwd has metacharacters, but...

Hi,

On Wed, 23 Nov 2005, Junio C Hamano wrote:

Obviously, this only works if the other side can connect to this side via ssh. Hmm. Firewalls? Disabled sshd? `hostname` not reliably returning a valid address for the remote side?

Hth, Dscho

On Thu, Nov 24, 2005 at 12:41:56AM +0100, Johannes Schindelin wrote:

If sshd is running locally, you can forward a port back to yourself and have the remote clone localhost:`pwd`. Assuming there's a way to clone using a nonstandard port.

Nick Hengeveld wrote:

ssh://host.xz:port/path/to/repo.git

should work. If it doesn't I'll fix it.

On Thu, 24 Nov 2005, Johannes Schindelin wrote:

Well, you could also just script it and just do

	ssh machine 'mkdir -p /path/to/new/repository ;
		cd /path/to/new/repo;
		git-init-db'
	git push --all machine:/path/to/new/repository
	ssh machine 'cd /path/to/new/repo ; git checkout'

(and yes, we could obviously make this a "git-create-repo" command, and then you could do

	git-send-pack --exec=git-create-repo \
		machine:/path/to/new/repository
		$(git-rev-parse --all)

or something like that).

		Linus