Re: git-daemon on NSLU2

On 8/26/07, Linus Torvalds [off-list ref] 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@gmail.com