Re: "git-send-pack"

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 30 Jun 2005, Mike Taht wrote:
> 
> >    However, I don't know what the rules for acceptable mirroring 
> >    approaches are, and it's entirely possible (nay, probable) that an ssh
> >    connection from the "master" ain't it. It would be good to know what 
> >    (of any) would be acceptable solutions..
> 
> Flute, perhaps
> 
> http://www.atm.tut.fi/mad/

Well, I was hoping for something that has git knowledge, since there are 
issues like updating objects in the right order. 

So "git-send-pack" is nice in many ways: it allows you to update any 
number of branches (in particular, it allows you to update just a _subset_ 
of the branches, which is nice if you have a shared central repository, 
and some people have write permissions to some branches but not to 
others), but it also allows for efficient unpacking on the receiver side 
in a way no "general-purpose" mirror program can really match.

However, that requires the receiver to run a git-aware unpacker (in this
case git-receive-pack). I'm hoping that would be acceptable, I'm just
wondering what kind of safety concerns I'd need to make sure of in order
to make people comfortable running a special receiver program.

So the current approach is very flexible: if the pusher has ssh access, he
can do it. Safe, secure, and no new security issues. And since the only
programs the receiver has to be able to run is two git programs
(git-receive-pack will run git-unpack-objects), maybe it would be ok to
even have "git-receive-pack" as the shell for the receiver side, so that
you don't actually give the mirrorer any shell access at all. But it's
still "push-based" in the sense that it's kernel.org that is doing the
pushing, and that may simply not be acceptable.

			Linus