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 <[EMAIL PROTECTED]> 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?
> 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.
> 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..
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
