On 8/26/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > And there's actually a deeper problem: the current native protocol > guarantees that the objects sent over are only those that are reachable. > That matters. It matters for subtle security issues (maybe you are > exporting some repository that was rebased, and has objects that you > didn't *intend* to make public!), but it also matters for issues like git > "alternates" files. Are these objects visible through the other protocols? It seems dangerous to leave something on an open server that you want to keep hidden. > If you only ever look at a single repo, you'll never see the alternates > issue, but if you're seriously looking at serving git repositories, I > don't really see the "single repo" case as being at all the most common or > interesting case. > > And if you look at something like kernel.org, the "alternates" thing is > *much* more important than how much memory git-daemon uses! Yes, > kernel.org would probably be much happier if git-daemon wasn't such a > memory pig occasionally, but on the other hand, the win from using > alternates and being able to share 99% of all objects in all the various > related kernel repositories is actually likely to be a *bigger* memory win > than any git-daemon memory usage, because now the disk caching works a > hell of a lot better! Doesn't kernel.org use alternates or something equivalent for serving up all those nearly identical kernel trees? I've been handling the problem locally by using remotes and fetching all the repos I'm interested in into a single git db. > > So it's not actually clear how the initial clone thing can be optimized on > the server side. > > It's easier to optimize on the *client* side: just do the initial clone > with rsync/http (and "git gc" it on the client afterwards), and then > change it to the git native protocol after the clone. Even better, get them to clone from kernel.org and then just fetch in the differences from my server. It's an educational problem. How about changing initial clone to refuse to use the git protocol? > > That may not sound very user-friendly, but let's face it, I think there is > exactly one person in the whole universe that tries to use an NSLU2 as a > git server. So the "client-side workaround" is likely to affect a very > limited number of clients ;) I'll send you one and double the size of the user base. I have this fancy new 20Mb FIOS connection and I can't come up with anything to use the bandwidth on. Anyway, I already gave up and moved on to a hosting provider. Repo is here: http://git.digispeaker.com/ There's nothing there yet but a clone of the 2.6 tree. I don't think there is a solution for running a git daemon on a shared host. Petr pointed out to me that an NSLU2 is late 90's equivalent not early so my memory if faulty too. > > Linus > -- Jon Smirl jonsmirl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
