Petr Baudis <pasky@xxxxxxx> wrote: > Dear diary, on Fri, Oct 27, 2006 at 02:29:10PM CEST, I got a letter > where "Horst H. von Brand" <vonbrand@xxxxxxxxxxxx> said that... > > I'm trying to set up git repos for remote access here. I set up git-daemon > > and got it working (some older repositories do work fine), but now: > > > > $ mkdir /var/scm/user/SomeRepo.git > > $ cd /var/scm/user/SomeRepo.git > > $ git --bare init-db > > $ touch git-daemon-export-ok > > > > All OK, but then, from a remote machine: > > > > $ git clone git://git-server/user/SomeRepo.git > > fatal: no matching remote head > > fetch-pack from 'git://git-server/user/Test.git' failed. > > The empty repo created by init-db should be cloneable, so as to get the > > ball rolling easily. > Well there's really nothing to clone, so it's tough. :-) What would such > a clone be supposed to do? It has no branches to record as belonging to > origin, and note that Git's git-clone is long-term broken in the sense > that it won't pick new branches as they appear in the remote > repository. So a clone of an empty repository would be useless anyway. As useless as the empty set? ;-) > > You can't push into such an empty repository either. > > This is supposed to work. What error do you get? Pilot error. Sorry for the noise. > > Any suggestion of how to set up a server into which users can create their > > own repos /without/ giving out full shell accounts? > > Sure: > > http://repo.or.cz/w/repo.git Cloning... "error: Can't lock ref" (?) OK, got it; the repo is at git://repo.or.cz/repo.git. Better not calling it *.git > But it may be quite an overkill for you. ;-) Will see. > If you want them to be able to do it over ssh, you would need to provide > a trusted tool which would manage the repository setup, that means not > only doing init-db, but also managing the export-ok files, description > file, you'd likely want to enable the post-update hook (but probably not > any other hook or let the user edit it since at that point you've given > him full shell access), etc. And the tool would have to be carefully > reviewed since it's security-critical. I was fearing something along these lines... > > Also, the behaviour of git-daemon is different when using git or ssh+git, > > you need to give the full path for the later but not the former (given > > --base-path=/var/scm): > > > > git://git-server/user/Test.git > > ssh+git://git-server/var/scm/user/Test.git > > > > Is this intentional? > > git+ssh has nothing to do with git-daemon, it's executing other git > commands remotely. OK. But from an UI POW it is confusing. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html