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. 

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

Reply via email to