Linus has guts

Posted Apr 14, 2005 9:58 UTC (Thu) by Tobu (subscriber, #24111)
Parent article: The guts of git

What a sucker, this Linus guy.

I mean: for years, he's been ignoring the free SCM, on the grounds that they "didn't scale" for such a large project as the kernel. When he finally is bitten, he still scorns the alternatives, and comes up with a downgraded monotone sketch.
Being something of a rockstar, he'll get away with it, and will get enough developper support because people must still be able to talk to his tree; but in terms of development time, he's just throwing others' work out of the window.

Linus has guts

Posted Apr 14, 2005 11:34 UTC (Thu) by filipjoelsson (guest, #2622) [Link] (1 responses)

Hmm, if it takes Linus two hours to merge a patch-bomb, I think he has put less time into developing this new foundation for an SCM - than he would have been spending waiting for one of the existing SCMs merging his patches over the next month or two.

Others are spending time inventing fancy algos, theories, and such, but fail on the real-world test. Why should Linus not scratch this desperate itch then? Why should he come to an existing project, and overturn it with his rather extreme demands? Does he have the time to wait for one of them to "grow up"? I think not. Remember that he is working full time, whereas many contributors to smaller projects are programming in their spare time. Thus, waiting on the spare-time programmers would be rather frustrating.

So, it's not a question about Linus being a rock star. It's a question of efficiency.

Linus has guts

Posted Apr 14, 2005 18:44 UTC (Thu) by dlang (guest, #313) [Link]

the other projects have had three years to develop a better SCM solution.

as Linux pointed out in the announcement that he was going to look at other options for SCM they aren't useable yet for something the size of the kernel yet.

we'll see if git ends up beng a dead-end system or the base for a better system in the future, but it has a very different focus then the other SCM options.

every one of the other options is starting with what the UI is, what commands the scm will implement. git is starting from the other direction and building the low-level pices (and building them to be fast) and then layering the UI on top of that.

this seems like a much better approach to take, and the other SCM systems can take advantage of these primitives as well (assuming they are willing to live with a linux-only limitation or the slowdown from other systems that don't have some of the underlying infrastructure that git is counting on in the OS for it's speed)

Linus has guts

Posted Apr 14, 2005 14:38 UTC (Thu) by kevinbsmith (guest, #4778) [Link]

At first, I thought Linus was wasting his time (and that of others) on git. It is still possible that he is, but if he really has found a super-simple alternative to the complexity of other distributed SCM systems, then he has really achieved something remarkable. Sometimes it takes an outsider to see what the experts overlook.

If (almost) anyone else had pitched this idea to him, I doubt Linus would have paid any attention. If (almost) anyone else had come up with git, they would not have immediately attracted a community of developers to help build it. Linus also has the advantage of targeting a single workflow process within a single project. That's far easier than creating a generic tool.

If someone can wrap a true, minimal but functional generic SCM around this thing, I will try it. I like minimalist simplicity. We should know within a few weeks whether the fundamental ideas are a good foundation, or have dead-end limitations. At the moment, I'm betting it will work.

One other thing: I wish the authors of the various free distributed SCM's could gather to critique git's future possibilities. Assuming they could set aside their own biases, they are in the best position to point out limitations and guide the design.

Linus has guts

Posted Mar 17, 2011 14:58 UTC (Thu) by nix (subscriber, #2304) [Link]

With six years' perspective, this comment is quite amusing. Most of the core of git is unchanged from this earliest sketch: one thing has been renamed (cache -> index), but the only major new concept is packfiles, which have zero impact on anything but disk space.

I think we can say that git is by now more than a 'downgraded monotone sketch' :)