I'm the author of the OP. The comments here make me think (again) that the article wasn't clear enough: admittedly, when I first wrote it, I was just discovering git, as some of the comments said. The difference between me and perhaps many recently-baptized git fanboys is that now, three years later, I still believe exactly what I wrote. I just now also know why it came across the wrong way.
Here's what I was trying to get across at the time: git creates a whole new set of nouns and verbs for computer science that almost none of us have experienced before. Yes, it steals a lot of concepts from programs like darcs and monotone, and there are other things that do the same things that git does from a VCS point of view - but my focus is on the nouns and verbs. git exposes the plumbing of these new concepts directly to you, which is both scary and intensely powerful.
git isn't the next Unix because it will replace Unix: git is the next Unix because its concepts represent the next mind-shifting change in computer science. I mean that git is the next Unix in the same way you could say "Unix is the next Lisp" or "Dynamic Languages are the next Static Languages." Not that the new thing replaces the old thing: they have totally different uses. But that's the point: the new thing's uses are really new. Stuff that was hard is now easy.
It's hard to imagine the world before Unix pipes (and the Unix sh in general) were invented, but I used it, and IT SUCKED. The whole Unix paradigm (yikes, now I've used that word) really changed the face of computing. Even if you don't use Unix, you got changed by Unix.
git's new nouns are blobs, trees, commits, and refs. The new verbs are push, pull, merge, tag, etc. You can apply these nouns and verbs to a lot more than just source code version control.
The naysayers in this thread all sound like 1990's programmers who don't understand the value of higher-order functions or dynamic typing or macros. You can survive without those things, but some problems are just so much easier with them than without them. git is like that. If you don't get it, you're living in the past.
One final clarification: my article was written to talk about git, but it's not about git's code or API or repo format at all. bup, the backup software I started writing about two years after that article, doesn't share any source code with git, but the amazing things it does are possible because it uses the new nouns and verbs popularized by git. When new distributed filesystems and databases and social networks and wikis and massively distributed collaborative text editors arrive, they will all be using these new nouns and verbs. If you don't care about that, then yeah, git isn't the next Unix for you. But if you want to build the next generation of networks in real life, then you'll either be taking advantage of the new nouns and verbs or you'll be painstakingly building the Windows of distributed systems.
> You can apply these nouns and verbs to a lot more than just source code version control.
Do you have any examples of people (other than you) who have actually done this? It would make your argument much more convincing.
Also, the fact that other DVCS's have different, incompatible models underlying them suggests that Git's nouns and verbs are not nearly as universal as Unix pipes. If Git's nouns and verbs were universal, Git could subsume other DVCS's (ie. you could implement other DVCS's semantics on top of Git with performance as good or better than what they have already).
Many of the new "nosql" databases use a lot of similar concepts. But it's a new thing: I'm trying to see into the future here, not tell you what's already happened :)
As for different DVCSs, I think you're exactly backwards. Almost everyone commenting on these things seems to believe that git isn't special, it really does the same thing as every other DVCS, etc. And on a fundamental level this is true: it's very easy to convert from one DVCS to another, because fundamentally the models are so similar. git just exposes the model in a more obvious way. The insides are the same, the outsides are different.
I thought I was with you but I was just made a little more confused by that comment :\
I've yet to do a lot with Git, but your post has made me a lot more interested. After wikipediaing the features, I'm starting to see how one could save a lot of time by building an app on top of Git rather than recreate all this functionality from scratch.
Here's what I was trying to get across at the time: git creates a whole new set of nouns and verbs for computer science that almost none of us have experienced before. Yes, it steals a lot of concepts from programs like darcs and monotone, and there are other things that do the same things that git does from a VCS point of view - but my focus is on the nouns and verbs. git exposes the plumbing of these new concepts directly to you, which is both scary and intensely powerful.
git isn't the next Unix because it will replace Unix: git is the next Unix because its concepts represent the next mind-shifting change in computer science. I mean that git is the next Unix in the same way you could say "Unix is the next Lisp" or "Dynamic Languages are the next Static Languages." Not that the new thing replaces the old thing: they have totally different uses. But that's the point: the new thing's uses are really new. Stuff that was hard is now easy.
It's hard to imagine the world before Unix pipes (and the Unix sh in general) were invented, but I used it, and IT SUCKED. The whole Unix paradigm (yikes, now I've used that word) really changed the face of computing. Even if you don't use Unix, you got changed by Unix.
git's new nouns are blobs, trees, commits, and refs. The new verbs are push, pull, merge, tag, etc. You can apply these nouns and verbs to a lot more than just source code version control.
The naysayers in this thread all sound like 1990's programmers who don't understand the value of higher-order functions or dynamic typing or macros. You can survive without those things, but some problems are just so much easier with them than without them. git is like that. If you don't get it, you're living in the past.
One final clarification: my article was written to talk about git, but it's not about git's code or API or repo format at all. bup, the backup software I started writing about two years after that article, doesn't share any source code with git, but the amazing things it does are possible because it uses the new nouns and verbs popularized by git. When new distributed filesystems and databases and social networks and wikis and massively distributed collaborative text editors arrive, they will all be using these new nouns and verbs. If you don't care about that, then yeah, git isn't the next Unix for you. But if you want to build the next generation of networks in real life, then you'll either be taking advantage of the new nouns and verbs or you'll be painstakingly building the Windows of distributed systems.