On Fri, 12 Aug 2005, Daniel Barkalow wrote:
>
> The git architecture makes the central server less important, and it's
> easy to run your own.
On the other hand:
- the git architecture is admirably suited to an _untrusted_ central
server, ie exactly the SourceForge kind of setup. I realize that the
people at SourceForge probably think they are trustworthy, but in the
big picture, even SF probably would prefer people to see them as a
_distribution_ point, not the final authority.
IOW, with git (unlike, for example CVS), you can have a useful
distribution point that is _not_ one that the developers have to
control or even necessarily want to control. Which is exactly the
kind of setup that would match what SF does.
So with git, developers don't have to trust SF, and if SF is down or
something bad happens (disk crash, bad backups, whatever), you didn't
"lose" anything - the real development wasn't being done at SF anyway,
it was a way to _connect_ the people who do real development.
- Every developer wants to have their own history and complete source
control, but very few developers actually have good distribution
resources. "kernel.org" works for a few projects, and might be fine to
expand a bit past what it does now, but kernel.org doesn't eevn try to
do (nor _want_ to do, I bet) the kinds of things that SF does.
Yes, developers can just merge with each other directly, and git allows
that, but it's actually not very convenient - not because of git
itself, but because of just doing the maintenance. For example, I don't
allow incoming traffic to my machines, and I feel _much_ better that
way. No MIS, no maintenance, and much fewer security issues.
This is _exactly_ where something like SF really ends up being helpful.
It's a _hosting_ service, and git is eminently suitable to being
hosted, exactly because of its distributed approach. It needs very few
hosting services: you could make do with a very very limited shell
access, and in fact I tried to design the "git push" protocol so that
you could give people ssh "shell" access, where the "shell" was not a
real shell at all, but something that literally just implemented four
or five commands ("git-receive-pack" and some admin commands to do
things like creation/removal of whole archives etc).
> Also, kernel.org is providing space to a set of people with a large
> overlap with git users, since git hasn't been particularly publicized
> and kernel.org is hosting git.
kernel.org certainly works well enough for the few projects that use it,
but I don't think it's going to expand all that much.
And it's possible that git usage won't expand all that much either. But
quite frankly, I think git is a lot better than CVS (or even SVN) by now,
and I wouldn't be surprised if it started getting some use outside of the
git-only and kernel projects once people start getting more used to it.
And so I'd be thrilled to have some site like SF support it.
bkbits.net used to do that for BK projects, and there were a _lot_ of
projects that used it.
Linus
-
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
