A discussion was raised as to whether or not GIT [story [1]] would be a service that should be provided by development websites like SourceForge [2]. Linus Torvalds suggested that this would be a good match-up. "The git architecture is admirably suited to an _untrusted_ central server," Linus explained, "ie exactly the SourceForge kind of setup." He went on to explain, "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."
As to whether or not this is likely to happen, Linus added, "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."
From: Wolfgang Denk [email blocked] To: git Subject: [OT?] git tools at SourceForge ? Date: Fri, 12 Aug 2005 21:07:39 +0200 This is somewhat off topic here, so I apologize, but I didn't know any better place to ask: Has anybody any information if SourceForge is going to provide git / cogito / ... for the projects they host? I asked SF, and they openend a new Feature Request (item #1252867); the message I received sounded as if I was the first person on the planet to ask... Am I really alone with this? Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email blocked] There are three things I always forget. Names, faces - the third I can't remember. - Italo Svevo
From: Daniel Barkalow [email blocked] Subject: Re: [OT?] git tools at SourceForge ? Date: Fri, 12 Aug 2005 16:46:34 -0400 (EDT) On Fri, 12 Aug 2005, Wolfgang Denk wrote: > This is somewhat off topic here, so I apologize, but I didn't know > any better place to ask: > > Has anybody any information if SourceForge is going to provide git / > cogito / ... for the projects they host? I asked SF, and they openend > a new Feature Request (item #1252867); the message I received sounded > as if I was the first person on the planet to ask... > > Am I really alone with this? The git architecture makes the central server less important, and it's easy to run your own. 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. -Daniel *This .sig left intentionally blank*
From: Linus Torvalds [email blocked] Subject: Re: [OT?] git tools at SourceForge ? Date: Fri, 12 Aug 2005 15:27:52 -0700 (PDT) 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
From: Martin Langhoff [email blocked] Subject: Re: [OT?] git tools at SourceForge ? Date: Sat, 13 Aug 2005 11:17:57 +1200 > - the git architecture is admirably suited to an _untrusted_ central > server, ie exactly the SourceForge kind of setup. I realize that the Definitely. And beyond that too. Using SF for CVS means that when SF's CVS service is down (often enough) you can't commit (or even fscking diff) until they are back up. Every single damn operation does a roundtrip. This also means a huge load on their servers. I'm sure SF will be glad to see CVS fall out of favour. > Yes, developers can just merge with each other directly I take it that you mean an exchange of patches that does not depend on having public repos. What are the mechanisms available on that front, other than patchbombs? > This is _exactly_ where something like SF really ends up being helpful. > It's a _hosting_ service, and git is eminently suitable to being Not sure whether SF is offering rsync, but they do support hosting of arbitrarty data -- and a project using GIT can use that to host several developer trees . It'd be nice if SF offered gitweb and similar niceties. As my usage of GIT increases, I may add support for it on Eduforge.org If I had more (hw/time) resources I'd do the git proxying of CVS projects, but that's huge. > And so I'd be thrilled to have some site like SF support it. Eduforge's charter is to host education-related projects, so that's not a free-for-all-comers, but I'm considering git support, as our usage of git is growing. cheers, martin
From: Linus Torvalds [email blocked] Subject: Re: [OT?] git tools at SourceForge ? Date: Fri, 12 Aug 2005 16:46:11 -0700 (PDT) On Sat, 13 Aug 2005, Martin Langhoff wrote: > > > Yes, developers can just merge with each other directly > > I take it that you mean an exchange of patches that does not depend on > having public repos. What are the mechanisms available on that front, > other than patchbombs? Just have a shared trusted machine. A lot of "core" developers end up having machines that they may not control, and that they may not be able to use as major distribution points, but that they _can_ share with others. For example, "master.kernel.org" ends up being that for the kernel: you don't have to have an account on master, but most of the core developers do, so they can use it as a short-cut that is independent of the actual "public" site. Similarly, some people are perfectly willing to give other trusted developers a ssh login on their machine - and that's a perfectly fine way to sync repositories directly if you have even a slow DSL link. You'd never want to _distribute_ the result over DSL, though. The point being that you can certainly sync up to others without going through a public site. [ We _could_ also just send pack-files as email attachments. There's nothing fundamentally wrong with doing the object discovery that "git-send-pack" does on its own manually over email. In other words: you could easily do something like "Hey, I've got your commit as of yesterday, ID <sha1>, can you send me your current top-of-tree SHA1 name and the pack-file between the two?" and have direct git-to-git synchronization even over email. NOTE NOTE NOTE! BK did this, with a "bk send" and "bk receive". I hated it, which is why I'd never do scripts like that. But I think it's a valid thing to do when you're cursing the fact that the central repository is down, and has been down for five hours, and you don't know how long it will take to get back up, and you don't have _any_ other choices ] > > This is _exactly_ where something like SF really ends up being helpful. > > It's a _hosting_ service, and git is eminently suitable to being > > Not sure whether SF is offering rsync, but they do support hosting of > arbitrarty data -- and a project using GIT can use that to host > several developer trees. The problem with the arbitrary data approach (and rsync) is that the git repositories can get out of sync. We haven't seen it very often on kernel.org, but we _do_ see it. I think I've got something like three bug reports from people saying "your tree is corrupted" because it so happened that the mirroring was on-going at the same time I did a push, and the mirroring caught an updated HEAD without actually having caught all of the objects that HEAD referenced. Now, all the git tools do write things in the right order, and mirror scripts etc _tend_ to mirror in alphabetical order (and "objects" come before "refs" ;), so you really have to hit the right window where a git tool updates the git repository at the same time as a mirroring sweep is going on, but it definitely _does_ happen. It just happens seldom enough that most people haven't noticed. But if you've seen the gitweb page go blank for one of the projects, you now know why it can happen.. And this is inevitable when you have a non-git-aware server. You really need to update the objects in the right order, and to get the right order you do have to be git-aware. > It'd be nice if SF offered gitweb and > similar niceties. As my usage of GIT increases, I may add support for > it on Eduforge.org I think we'll find that it's a learning process, to just find out what drives site managers mad (we certainly found the problem with lots of small files on kernel.org out ;). Having a few sites that do it and tell the others what gotchas there are involved with it (and what scripts they use for maintaining stuff like auto-packing etc) is all a learning experience. Linus
Related Links:
- Archive of above thread [3]