Linus Torvalds <[EMAIL PROTECTED]> writes:
> 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.
Have you not looked at tla/arch? tla does supports dumb servers.
It's job is a little easier as it has one file per atomic commit
I suspect once packs start working well that should not be an
issue for git either.
For small projects this is a major benefit, as they can just push
their files to a convenient http or ftp server.
> 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.
For optimizing network bandwidth that sounds like the way to go. For
adhoc development I don't know. For a central sever you still need
an authenticated way to push content, which makes it another dimension
of the problem. So it is mostly a question of what is the sanest way
to mirror/publish data. http is used a lot for publishing data and
practically everyone has access to a http server that can host
content, so I think supporting http makes git a lot more accessible
to people. The only thing more accessible seems to be email, and
email is terrible for publish small projects.
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