Interesting read Posted May 2, 2005 23:16 UTC (Mon) by kasperd (guest, #11842) [Link] (6 responses) It sounds like Linus really has been thinking about what he wants and came up with a good clean design for that. But well he does sound a litle bit irritated by people not yet understanding this design. I count eight uses of the word dammit. Let's hope this settles down soon as it really starts working well. I really believe Linus got the design right. I also like the idea about this signed tags, which are just pointers to a version of the tree. And though Linus himself states, that he is not really into this PGP stuff, I must say that (assuming I got the explanation right) the way it is done is fundamentally right. Since it is sha1 hashes all the way down to the source files, it should be as safe as a digital signature on the tarball (And I do have a background in cryptography). The only place it seems he didn't make the right decision was when he decided not to include the 3GB of reversion history all the way back to 2.4. Though nobody might want it now, probably it will be wanted in the future. As Thomas Gleixner pointed out, it doesn't need to be in all the repositories, but we need the pointer back in case anybody eventually want to use git to look back on past revesion history. Old kernel history Posted May 3, 2005 3:16 UTC (Tue) by kevinbsmith (guest, #4778) [Link] There has been at least one proposal for how to "insert" the older kernel history later, so there is no rush. It's a variation on the (future) feature of being able to "prune" (discard) some older history of any project. Don't panic :-) Interesting read Posted May 3, 2005 4:39 UTC (Tue) by aquasync (guest, #26654) [Link] (3 responses) What I don't like about it, is that the SHA1's are of the compressed data. It makes more sense pragmatically, but I don't like it that the `signature' of a file depends on how it is compressed. Interesting read Posted May 3, 2005 5:00 UTC (Tue) by lutchann (subscriber, #8872) [Link] (2 responses) If you'd actually read the 79 pages (yeah right, it took me like two hours), buried somewhere in there is a thread in which Linus converts git to do the SHA-1 hash *before* the compression. Item #24, it looks like. This solved some performance issues since it was no longer necessary to compress a file in the working copy to see if it needed to be stored in the repository, and it also left the door open to change the compression format in the future. Interesting read Posted May 3, 2005 8:08 UTC (Tue) by aquasync (guest, #26654) [Link] (1 responses) Yeah you're right, I hadn't yet read it :). It was more something that was annoying me since an earlier article. I thought that path had been chosen for quicker verification (in fact I think that was an attribute mentioned), and that the fact that the signature changes with compression method was ignored because if something is recompressed, it probably has changed. (of course, if the compression method has changed inbetween a file going to the working-copy, and back to the tree, a spurious change would be recorded). Anyway, nice to see thats changed. I had some other small nit-picks, but they've likely been addressed when this many people think about something (huge thread!), now I'll just have to read it to find out... Interesting read Posted May 3, 2005 13:48 UTC (Tue) by lutchann (subscriber, #8872) [Link] Interestingly, git doesn't seem to verify the contents of the objects against the hash very often, so it ended up being silly to optimize for this case rather than for the more frequent case of wanting to write your changes into the repository. Interesting read Posted May 3, 2005 7:17 UTC (Tue) by Wol (subscriber, #4433) [Link] "But well he does sound a litle bit irritated by people not yet understanding this design." The trouble is that too many people have frozen mindsets ... Git is NOT a source code control system. It's a source code repository. BIG BIG BIG difference !!! Linus got pissed off in the past with people pointing him at Subversion et al, and this is just more of the same. The people who can't grok why Subversion is the solution to the wrong problem are the same people who can't grok that git is not an SCCS. Unfortunately, they also seem to be quite vocal (as many people are when they can't see the other guy's point of view - "if you're wrong, then shout louder" :-( Cheers, Wol Git Traffic #1 Posted May 3, 2005 3:55 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (9 responses) I love this already. Part of the real joy I get from using Linux is not the fact that I can make any changes I want (I like that!), or that I can get good help from the developers themselves quite often (I like that too!), or even that I get to have tools which are simply better (I like that three!). No, the real joy, for me, is seeing how the coders put stuff together. Watching minds meet and come up with solutions is fascinating to me, and watching true masters at work, as I see here, is really special. Linus' whole explanation on just why file renames need not be tracked, and how to handle that case on a more general level, is just one example: he's somehow managed to just look at the problem and say "Wait a sec, this doesn't even matter!" in a way that is just...well, I think Jon Corbet has described these as "Linus moments", no? Git Traffic #1 Posted May 3, 2005 14:41 UTC (Tue) by alq666 (guest, #11220) [Link] (8 responses) He also have moments of Not-Invented-Here syndrome. From what I've read he's re-created a file-based database. Git Traffic #1 Posted May 3, 2005 16:44 UTC (Tue) by lutchann (subscriber, #8872) [Link] A lot of the ideas Linus is using in git have certainly been borrowed from other places, sure. However, he's particularly good at combining well-known but proven concepts with exceptionally good engineering, both in the design and in the code itself, resulting in an end-product that shines at every level. There's a lot of truth to saying that Linux itself was a result of NIH, but these days nobody would criticize it for that. Sometimes it takes a healthy dose of self-righteousness to get things done the right way. Git Traffic #1 Posted May 3, 2005 17:53 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (6 responses) I don't think it's so much "NIH" as "this sucks, change it!" Existing version control systems that were not BitKeeper sucked for the kernel's development model (they probably work fine for other, more centralized models). BitKeeper was no longer an option, so Linus was kind of forced to craft his own plumbing for one. And perhaps he could have used an existing file database, such as Berkley DB, but on the other hand, maybe not. What does appear to be the case, however, is that git A) works, B) works well, and C) works FAST. I think those are things of value, not just to the kernel folks, but to SCM at large (witness Arch and DARCS moving to use git as a backend). what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:15 UTC (Wed) by zooko (guest, #2589) [Link] (5 responses) Linux has also commented that existing version control systems were too centralized. This perplexes me, since among the ones that I have been tracking for the last year or so at http://zooko.com/revision_control_quick_ref.html , they are all at least as decentralized as BitKeeper, with the exceptions of Subversion and Aegis. It's possible that Linus is thinking of some aspect of workflow that I am missing, but currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk. Regards, Zooko what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:16 UTC (Wed) by zooko (guest, #2589) [Link] Bah, I meant "Linus" there, not "Linux". what are these centralized systems that people keep mentioning? Posted May 4, 2005 19:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses) Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. And my experience with Arch agrees: it fell to uselessness with a mere 7000 file repository. I can't imagine trying to keep the Kernel in it. currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk No way. Linus appears to understand them very well. I think he's even offered suggestions to the Darcs guys which they are adopting... Since I can't immediately find a link though, I might not be remembering correctly. what are these centralized systems that people keep mentioning? Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses) > Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up. (Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?) what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today. Git Traffic #1 Posted May 3, 2005 17:48 UTC (Tue) by shieldsd (guest, #20198) [Link] Absolute fascinating. The speed of development and quality of the work is breathtaking. If you ever had ANY doubts about the quality of the Linux developers (I don't) reading this should dispel them.
Posted May 2, 2005 23:16 UTC (Mon) by kasperd (guest, #11842) [Link] (6 responses)
I also like the idea about this signed tags, which are just pointers to a version of the tree. And though Linus himself states, that he is not really into this PGP stuff, I must say that (assuming I got the explanation right) the way it is done is fundamentally right. Since it is sha1 hashes all the way down to the source files, it should be as safe as a digital signature on the tarball (And I do have a background in cryptography).
The only place it seems he didn't make the right decision was when he decided not to include the 3GB of reversion history all the way back to 2.4. Though nobody might want it now, probably it will be wanted in the future. As Thomas Gleixner pointed out, it doesn't need to be in all the repositories, but we need the pointer back in case anybody eventually want to use git to look back on past revesion history.
Old kernel history Posted May 3, 2005 3:16 UTC (Tue) by kevinbsmith (guest, #4778) [Link] There has been at least one proposal for how to "insert" the older kernel history later, so there is no rush. It's a variation on the (future) feature of being able to "prune" (discard) some older history of any project. Don't panic :-) Interesting read Posted May 3, 2005 4:39 UTC (Tue) by aquasync (guest, #26654) [Link] (3 responses) What I don't like about it, is that the SHA1's are of the compressed data. It makes more sense pragmatically, but I don't like it that the `signature' of a file depends on how it is compressed. Interesting read Posted May 3, 2005 5:00 UTC (Tue) by lutchann (subscriber, #8872) [Link] (2 responses) If you'd actually read the 79 pages (yeah right, it took me like two hours), buried somewhere in there is a thread in which Linus converts git to do the SHA-1 hash *before* the compression. Item #24, it looks like. This solved some performance issues since it was no longer necessary to compress a file in the working copy to see if it needed to be stored in the repository, and it also left the door open to change the compression format in the future. Interesting read Posted May 3, 2005 8:08 UTC (Tue) by aquasync (guest, #26654) [Link] (1 responses) Yeah you're right, I hadn't yet read it :). It was more something that was annoying me since an earlier article. I thought that path had been chosen for quicker verification (in fact I think that was an attribute mentioned), and that the fact that the signature changes with compression method was ignored because if something is recompressed, it probably has changed. (of course, if the compression method has changed inbetween a file going to the working-copy, and back to the tree, a spurious change would be recorded). Anyway, nice to see thats changed. I had some other small nit-picks, but they've likely been addressed when this many people think about something (huge thread!), now I'll just have to read it to find out... Interesting read Posted May 3, 2005 13:48 UTC (Tue) by lutchann (subscriber, #8872) [Link] Interestingly, git doesn't seem to verify the contents of the objects against the hash very often, so it ended up being silly to optimize for this case rather than for the more frequent case of wanting to write your changes into the repository. Interesting read Posted May 3, 2005 7:17 UTC (Tue) by Wol (subscriber, #4433) [Link] "But well he does sound a litle bit irritated by people not yet understanding this design." The trouble is that too many people have frozen mindsets ... Git is NOT a source code control system. It's a source code repository. BIG BIG BIG difference !!! Linus got pissed off in the past with people pointing him at Subversion et al, and this is just more of the same. The people who can't grok why Subversion is the solution to the wrong problem are the same people who can't grok that git is not an SCCS. Unfortunately, they also seem to be quite vocal (as many people are when they can't see the other guy's point of view - "if you're wrong, then shout louder" :-( Cheers, Wol
Posted May 3, 2005 3:16 UTC (Tue) by kevinbsmith (guest, #4778) [Link]
Don't panic :-)
Posted May 3, 2005 4:39 UTC (Tue) by aquasync (guest, #26654) [Link] (3 responses)
Interesting read Posted May 3, 2005 5:00 UTC (Tue) by lutchann (subscriber, #8872) [Link] (2 responses) If you'd actually read the 79 pages (yeah right, it took me like two hours), buried somewhere in there is a thread in which Linus converts git to do the SHA-1 hash *before* the compression. Item #24, it looks like. This solved some performance issues since it was no longer necessary to compress a file in the working copy to see if it needed to be stored in the repository, and it also left the door open to change the compression format in the future. Interesting read Posted May 3, 2005 8:08 UTC (Tue) by aquasync (guest, #26654) [Link] (1 responses) Yeah you're right, I hadn't yet read it :). It was more something that was annoying me since an earlier article. I thought that path had been chosen for quicker verification (in fact I think that was an attribute mentioned), and that the fact that the signature changes with compression method was ignored because if something is recompressed, it probably has changed. (of course, if the compression method has changed inbetween a file going to the working-copy, and back to the tree, a spurious change would be recorded). Anyway, nice to see thats changed. I had some other small nit-picks, but they've likely been addressed when this many people think about something (huge thread!), now I'll just have to read it to find out... Interesting read Posted May 3, 2005 13:48 UTC (Tue) by lutchann (subscriber, #8872) [Link] Interestingly, git doesn't seem to verify the contents of the objects against the hash very often, so it ended up being silly to optimize for this case rather than for the more frequent case of wanting to write your changes into the repository.
Posted May 3, 2005 5:00 UTC (Tue) by lutchann (subscriber, #8872) [Link] (2 responses)
Interesting read Posted May 3, 2005 8:08 UTC (Tue) by aquasync (guest, #26654) [Link] (1 responses) Yeah you're right, I hadn't yet read it :). It was more something that was annoying me since an earlier article. I thought that path had been chosen for quicker verification (in fact I think that was an attribute mentioned), and that the fact that the signature changes with compression method was ignored because if something is recompressed, it probably has changed. (of course, if the compression method has changed inbetween a file going to the working-copy, and back to the tree, a spurious change would be recorded). Anyway, nice to see thats changed. I had some other small nit-picks, but they've likely been addressed when this many people think about something (huge thread!), now I'll just have to read it to find out... Interesting read Posted May 3, 2005 13:48 UTC (Tue) by lutchann (subscriber, #8872) [Link] Interestingly, git doesn't seem to verify the contents of the objects against the hash very often, so it ended up being silly to optimize for this case rather than for the more frequent case of wanting to write your changes into the repository.
Posted May 3, 2005 8:08 UTC (Tue) by aquasync (guest, #26654) [Link] (1 responses)
Interesting read Posted May 3, 2005 13:48 UTC (Tue) by lutchann (subscriber, #8872) [Link] Interestingly, git doesn't seem to verify the contents of the objects against the hash very often, so it ended up being silly to optimize for this case rather than for the more frequent case of wanting to write your changes into the repository.
Posted May 3, 2005 13:48 UTC (Tue) by lutchann (subscriber, #8872) [Link]
Posted May 3, 2005 7:17 UTC (Tue) by Wol (subscriber, #4433) [Link]
The trouble is that too many people have frozen mindsets ...
Git is NOT a source code control system. It's a source code repository. BIG BIG BIG difference !!!
Linus got pissed off in the past with people pointing him at Subversion et al, and this is just more of the same. The people who can't grok why Subversion is the solution to the wrong problem are the same people who can't grok that git is not an SCCS. Unfortunately, they also seem to be quite vocal (as many people are when they can't see the other guy's point of view - "if you're wrong, then shout louder" :-(
Cheers, Wol
Posted May 3, 2005 3:55 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (9 responses)
No, the real joy, for me, is seeing how the coders put stuff together. Watching minds meet and come up with solutions is fascinating to me, and watching true masters at work, as I see here, is really special.
Linus' whole explanation on just why file renames need not be tracked, and how to handle that case on a more general level, is just one example: he's somehow managed to just look at the problem and say "Wait a sec, this doesn't even matter!" in a way that is just...well, I think Jon Corbet has described these as "Linus moments", no?
Git Traffic #1 Posted May 3, 2005 14:41 UTC (Tue) by alq666 (guest, #11220) [Link] (8 responses) He also have moments of Not-Invented-Here syndrome. From what I've read he's re-created a file-based database. Git Traffic #1 Posted May 3, 2005 16:44 UTC (Tue) by lutchann (subscriber, #8872) [Link] A lot of the ideas Linus is using in git have certainly been borrowed from other places, sure. However, he's particularly good at combining well-known but proven concepts with exceptionally good engineering, both in the design and in the code itself, resulting in an end-product that shines at every level. There's a lot of truth to saying that Linux itself was a result of NIH, but these days nobody would criticize it for that. Sometimes it takes a healthy dose of self-righteousness to get things done the right way. Git Traffic #1 Posted May 3, 2005 17:53 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (6 responses) I don't think it's so much "NIH" as "this sucks, change it!" Existing version control systems that were not BitKeeper sucked for the kernel's development model (they probably work fine for other, more centralized models). BitKeeper was no longer an option, so Linus was kind of forced to craft his own plumbing for one. And perhaps he could have used an existing file database, such as Berkley DB, but on the other hand, maybe not. What does appear to be the case, however, is that git A) works, B) works well, and C) works FAST. I think those are things of value, not just to the kernel folks, but to SCM at large (witness Arch and DARCS moving to use git as a backend). what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:15 UTC (Wed) by zooko (guest, #2589) [Link] (5 responses) Linux has also commented that existing version control systems were too centralized. This perplexes me, since among the ones that I have been tracking for the last year or so at http://zooko.com/revision_control_quick_ref.html , they are all at least as decentralized as BitKeeper, with the exceptions of Subversion and Aegis. It's possible that Linus is thinking of some aspect of workflow that I am missing, but currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk. Regards, Zooko what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:16 UTC (Wed) by zooko (guest, #2589) [Link] Bah, I meant "Linus" there, not "Linux". what are these centralized systems that people keep mentioning? Posted May 4, 2005 19:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses) Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. And my experience with Arch agrees: it fell to uselessness with a mere 7000 file repository. I can't imagine trying to keep the Kernel in it. currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk No way. Linus appears to understand them very well. I think he's even offered suggestions to the Darcs guys which they are adopting... Since I can't immediately find a link though, I might not be remembering correctly. what are these centralized systems that people keep mentioning? Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses) > Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up. (Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?) what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 3, 2005 14:41 UTC (Tue) by alq666 (guest, #11220) [Link] (8 responses)
Git Traffic #1 Posted May 3, 2005 16:44 UTC (Tue) by lutchann (subscriber, #8872) [Link] A lot of the ideas Linus is using in git have certainly been borrowed from other places, sure. However, he's particularly good at combining well-known but proven concepts with exceptionally good engineering, both in the design and in the code itself, resulting in an end-product that shines at every level. There's a lot of truth to saying that Linux itself was a result of NIH, but these days nobody would criticize it for that. Sometimes it takes a healthy dose of self-righteousness to get things done the right way. Git Traffic #1 Posted May 3, 2005 17:53 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (6 responses) I don't think it's so much "NIH" as "this sucks, change it!" Existing version control systems that were not BitKeeper sucked for the kernel's development model (they probably work fine for other, more centralized models). BitKeeper was no longer an option, so Linus was kind of forced to craft his own plumbing for one. And perhaps he could have used an existing file database, such as Berkley DB, but on the other hand, maybe not. What does appear to be the case, however, is that git A) works, B) works well, and C) works FAST. I think those are things of value, not just to the kernel folks, but to SCM at large (witness Arch and DARCS moving to use git as a backend). what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:15 UTC (Wed) by zooko (guest, #2589) [Link] (5 responses) Linux has also commented that existing version control systems were too centralized. This perplexes me, since among the ones that I have been tracking for the last year or so at http://zooko.com/revision_control_quick_ref.html , they are all at least as decentralized as BitKeeper, with the exceptions of Subversion and Aegis. It's possible that Linus is thinking of some aspect of workflow that I am missing, but currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk. Regards, Zooko what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:16 UTC (Wed) by zooko (guest, #2589) [Link] Bah, I meant "Linus" there, not "Linux". what are these centralized systems that people keep mentioning? Posted May 4, 2005 19:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses) Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. And my experience with Arch agrees: it fell to uselessness with a mere 7000 file repository. I can't imagine trying to keep the Kernel in it. currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk No way. Linus appears to understand them very well. I think he's even offered suggestions to the Darcs guys which they are adopting... Since I can't immediately find a link though, I might not be remembering correctly. what are these centralized systems that people keep mentioning? Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses) > Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up. (Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?) what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 3, 2005 16:44 UTC (Tue) by lutchann (subscriber, #8872) [Link]
There's a lot of truth to saying that Linux itself was a result of NIH, but these days nobody would criticize it for that. Sometimes it takes a healthy dose of self-righteousness to get things done the right way.
Posted May 3, 2005 17:53 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (6 responses)
what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:15 UTC (Wed) by zooko (guest, #2589) [Link] (5 responses) Linux has also commented that existing version control systems were too centralized. This perplexes me, since among the ones that I have been tracking for the last year or so at http://zooko.com/revision_control_quick_ref.html , they are all at least as decentralized as BitKeeper, with the exceptions of Subversion and Aegis. It's possible that Linus is thinking of some aspect of workflow that I am missing, but currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk. Regards, Zooko what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:16 UTC (Wed) by zooko (guest, #2589) [Link] Bah, I meant "Linus" there, not "Linux". what are these centralized systems that people keep mentioning? Posted May 4, 2005 19:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses) Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. And my experience with Arch agrees: it fell to uselessness with a mere 7000 file repository. I can't imagine trying to keep the Kernel in it. currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk No way. Linus appears to understand them very well. I think he's even offered suggestions to the Darcs guys which they are adopting... Since I can't immediately find a link though, I might not be remembering correctly. what are these centralized systems that people keep mentioning? Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses) > Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up. (Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?) what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 4, 2005 10:15 UTC (Wed) by zooko (guest, #2589) [Link] (5 responses)
Linux has also commented that existing version control systems were too centralized. This perplexes me, since among the ones that I have been tracking for the last year or so at http://zooko.com/revision_control_quick_ref.html , they are all at least as decentralized as BitKeeper, with the exceptions of Subversion and Aegis.
It's possible that Linus is thinking of some aspect of workflow that I am missing, but currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk.
Regards,
Zooko
what are these centralized systems that people keep mentioning? Posted May 4, 2005 10:16 UTC (Wed) by zooko (guest, #2589) [Link] Bah, I meant "Linus" there, not "Linux". what are these centralized systems that people keep mentioning? Posted May 4, 2005 19:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses) Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. And my experience with Arch agrees: it fell to uselessness with a mere 7000 file repository. I can't imagine trying to keep the Kernel in it. currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk No way. Linus appears to understand them very well. I think he's even offered suggestions to the Darcs guys which they are adopting... Since I can't immediately find a link though, I might not be remembering correctly. what are these centralized systems that people keep mentioning? Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses) > Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up. (Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?) what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 4, 2005 10:16 UTC (Wed) by zooko (guest, #2589) [Link]
Posted May 4, 2005 19:14 UTC (Wed) by bronson (subscriber, #4806) [Link] (3 responses)
currently it appears to me that Linus doesn't understand the decentralized designs of arch/arx/baz, monotone, codeville, darcs, vesta, or svk
No way. Linus appears to understand them very well. I think he's even offered suggestions to the Darcs guys which they are adopting... Since I can't immediately find a link though, I might not be remembering correctly.
what are these centralized systems that people keep mentioning? Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses) > Darcs, Monotone and Arch weren't rejected because they were too centralized. They were rejected because they were too slow. It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up. (Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?) what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 4, 2005 23:26 UTC (Wed) by piman (guest, #8957) [Link] (2 responses)
It's unfair to compare Darcs/Monotone/Arch (SCMs) to Git (a filesystem). When someone implements a tool with the usability and features of a modern SCM over Git, then we'll see if its speed holds up.
(Or is it only fair to point out "Git isn't an SCM" when the end-result is favorable to Git?)
what are these centralized systems that people keep mentioning? Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Quite true; git is not an SCM, it is a filesystem and plumbing for one. Cogito, the in-progress frontend to git, however, is a (beginning of) an SCM, and its speed is holding up quite well. So far. I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no? what are these centralized systems that people keep mentioning? Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link] If one of Darcs/Monotone/Arch was fast enough for Linus, he would have adopted it in a heartbeat. I'm pretty sure he didn't actually want to write the foundation for yet another SCM. He's a kernel developer! But he was forced to because all of the existing ones were either too centralized (svn) or had architectures that ensured that they were way too slow (the rest). So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 5, 2005 1:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
I don't think that git with Cogito will make other version control systems obsolete; it may, however, spur them to develop in new and interesting ways. And even if it doesn't, and it only ends up being a very good system for the kernel developers, that's quite enough, no?
Posted May 5, 2005 14:07 UTC (Thu) by bronson (subscriber, #4806) [Link]
So Linus invented a remarkably capable back-end and other people will lay SCM features on top. Soon (matter of weeks even?) there will be an SCM that uses Git. I'm confident that the Git/Cogito/whatever combo will be WAY faster than any other decentralized open source SCM in existence today.
Posted May 3, 2005 17:48 UTC (Tue) by shieldsd (guest, #20198) [Link]
Copyright © 2005, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
LWN