Petr Baudis <pasky@suse.cz> wrote:
quoted text
> Dear diary, on Fri, Oct 27, 2006 at 02:29:10PM CEST, I got a letter
> where "Horst H. von Brand" <vonbrand@inf.utfsm.cl> 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.

quoted text
> > The empty repo created by init-db should be cloneable, so as to get the
> > ball rolling easily.

quoted text
> 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? ;-)

quoted text
> > 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.

quoted text
> > 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

quoted text
> But it may be quite an overkill for you. ;-)

Will see.

quoted text
> 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...

quoted text
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html