Re: [ANNOUNCE] Cogito-0.12

From: Petr Baudis <pasky@suse.cz>
Date: Jul 7, 2005, 22:14 UTC
Message-ID: <20050707221443.GB7151@pasky.ji.cz>
In-Reply-To: <Pine.LNX.4.58.0507071158220.3293@g5.osdl.org>

Let me join the sceptics camp. :-)

Dear diary, on Thu, Jul 07, 2005 at 09:04:58PM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

> Note that I just re-packed the kernel archive on kernel.org, and removed 
> _all_ unpacked files. Once that percolates to the mirrors, the http 
> protocol will be useless without anything like this.

*grumble*

So, what _is_ then the way to pull now, actually? If we use rsync, won't we end up with having the objects we previous had twice now?

Show 5 quoted lines

> That said, I really think the dumb protocols are useless anyway. No other 
> system supports pure static object pulling anyway, and as far as I'm 
> concerned, I want "rsync" to kind of work (but it won't be optimal, since 
> re-packing will delete all the old objects and replace it with the new 
> pack that is downloaded anew). But plain http? I'm not convinced.

You can always just spider the repository which will work just as well as rsync in the git case. ;-)

I think it would be actually simplest (for the user) to have a trivial CGI script on the other side which will do the git-upload-pack stuff. Minimal extra administrative overhead, flexibility, works through proxies, and stuff. People can rewrite it in Perl or PHorridP if they wish and use it on webhosting servers not allowing much else.

That's not to say a dedicated server wouldn't have its place too, and that's what's now probably simplest for us. ;-)

Now we are in a situation when there's actually no way to pull from your kernel repository without throwing own repository to mess and duplicating data, AFAICS.

Show 13 quoted lines

> I'd much rather have a "stupid server" that just listens to a port, and
> basically forks off and executes "git-upload-pack" when it's connected to
> (perhaps reading the directory name first).  Nothing else. Then we can do 
> a security analysis of upload-pack, which should be fairly easy since it's 
> not actually ever _writing_ anything.
> 
> At that point, you can do
> 
> 	git pull git://www.kernel.org/pub/scm/git/..
> 
> and it would just connect to some default "git port", pass off the 
> directory name, and be done with it - exact same discovery protocol that 
> now use for ssh. And "git clone" would also automatically work.

Eek. Could you please make it at least pretend to be extensible? Compare git-upload-pack with git-ssh-pu* - the second one prepends letters to the data it sends so that if you add a new type of stuff to send (say for authentication or some smart tags stuff), you could extend it in a sensible way. What about dividing the communication to "blocks" separated by a newline? Each block would have its first word on the first line saying what kind of block it is - "refs", "have", "want", or "pack" (for simplicity, the pack block might have additional restriction that it's always the last one). If you hit unknown block, you should respond back by something like "huh" and ignore the rest of it.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..