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. Eric - 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
