Brian May wrote: >>>>>> "Graydon" == Graydon Hoare <[EMAIL PROTECTED]> writes: > > Graydon> Nuno Lucas wrote: > >>> Maybe I got this wrong, but based on what I have seen so far > >>> of this talk, I couldn't help but think that Linus didn't > >>> consult the Monotone developers with his concerns about speed, > >>> why it was slow, or how much work it would take to improve its > >>> speed.
I haven't really used git but I've read over some of the docs and certain aspects of the design seem quite nice (the blob/tree/commit structures for example). These are very similar to monotone and this nice design was also what originally attracted me to monotone. One thing Linus mentions in the talk is that a function moving from one file to another would be recognized by annotate because of the fact/way that git tracks content. This sounds interesting and I'm curious as to what it looks like in practice. The ui/command-set in git seems complicated and somewhat strange though. For example the fact that pull does fetch+merge seems a bit odd coming from monotone. It almost seems like "fetch" should have been called "pull" and "merge" could have been called "update" to maintain some command consistency. In terms of performance, I did a very quick test today on a ~30,000 file tree and git status took ~0.6 seconds while monotone (with inodeprints on) took ~3.5 seconds. Personally, ~3.5 seconds doesn't really offend me and I'm curious as to how much sha1 consistency checking git is doing generally when compared with monotone. I suspect it's doing somewhat less verification of things. Anyway, I should play around with it some more, it does seem reasonable and there's nothing wrong with fast! Cheers, Derek _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel