I don't understand why programmers - a crowd on whom you can usually rely to have healthy amount of hatred for competing technologies - became suddenly so lovey-dovey when it came to DVCSs.
Here's an example.
This is all wrong. Mercurial should die. So should bazaar, darcs, and countless other systems I won't even bother listing here. Why?
The best tool for the job fallacy
Very often people act as if choices made by one person in one context didn't affect other people, or even the same person in other contexts. What's the name of this problem? Externality denialism - that's what it is!It makes very little difference what font you use in your editor - if every single person used different fonts and different colours, nobody would suffer from it, except for maybe occasional odd person forced to work on someone else's machine and have their eyes burned by Comics Sans. Best font for the job, whatever.
And it likewise makes very little difference which editor you're using (well, maybe there would be more nice plug-ins if everyone used TextMate, but the effect is not that big), or which DVCS GUI frontend, and so on.
It makes some difference what programming language you use. If everyone used one of the small number of programming languages, they would have all the libraries, all the tools, and all the support needed. But if everyone uses something else - some use RLisp, some use colorForth, some use Megan-Fox-picture - the resulting chaos means nobody has tools, libraries, or support needed to do any work done. Yes, Megan-Fox-picture might be a better language than Ruby, but the net effect of everybody using a different language is a disaster.
Does it mean everyone should use Java? Not necessarily. It only means that the threshold for choosing an unusual language should be considerably higher than "slightly better tool for the job". Is Ruby better enough than Java? Obviously. If we lived in alternative world in which everyone used Python, would it make sense to write your program in Ruby? Well, it's a borderline case, but maybe, maybe not. Should we rewrite Linux kernel in Scheme? Maybe not. Or we could have different languages for genuinely different situations - with each dominating a well specified niche.
And even with programming languages it's not such big of a deal if you use an unusual language every now and then. Programs just do stuff. They can survive on their own. And most programming languages, diverse as they are, rely on the same standards for interoperability - POSIX, Unicode, TCP/IP and so on. Even if your program is written in LOLCODE, and mine in Clojure they can probably talk with each other reasonably well.
It can get painful if interaction gets too close - for example if a C library with fake OO is used from Ruby, and memory management of both is entirely incompatible and results in random memory leaks - yes I'm talking to you Gtk+ (not that anybody cares, Linux on desktop is dead). But basic interactions between different programs sort should work even across language gap.
Version Control Systems
It's not so with DVCSs. DVCSs are interoperability technology. If I like git and you like Mercurial we cannot just both "use best tool for the job", as neither of us will be able to talk to another. Imagine that in addition to HTTP, HTML, CSS and so on, Microsoft released its Microsoft Transfer Protocol, Microsoft Markup Language, and so on - do you have any idea how much mess it would get us into? Oh wait, we're already sort of there.Here's the game theoretic matrix for DVCS choice. Let's say half of developers like git more and half like Mercurial more:
- everyone uses git - Mercurial-lovers a bit grumpy, but otherwise we're all happy and interoperable
- everyone uses Mercurial - git-lovers a bit grumpy, but otherwise we're all happy and interoperable
- git-lovers use git, Mercurial-lovers use Mercurial - there is no interoperability and everyone suffers
- git-lovers use Mercurial, Mercurial-lovers use git - now that's just being silly
The solution? We have to agree to one DVCS or another. Yes, some day someone will make even better one, and we'll all switch again, but neither git nor Mercurial are sufficiently better from the other to win on merits alone, and there's really no point in having them both.
Right now git is significantly more popular. So what should happen? Mercurial should die. Yes, you put a lot of effort into it, and we're very sorry etc. etc. but seriously - we need a second DVCS as much as we need a second character set, or a second .
24 comments:
Frankly, mercurial is a _hell_ of a lot easier to adapt to than git. I had to do almost no work whatsoever to start using mercurial, while git is still, essentially, a large number of confusing commands that bear absolutely no relationship to any preceding VCS out there. I don't give one whit what Linus uses or created for his own use, mercurial is, simply put, a much easier transition from CVS or SVN. I say this after spending literally months evaluating various dVCS systems. Maybe I'm just stuck in my ways, but a system that makes _sense_ without a major retraining seems like the easier win. Alas, so many people have jumped on the "Linus uses git, so I should too" bandwagon, that it's a losing battle from where I'm sitting, but it doesn't change the fact that anyone used to a centralized VCS is likely to find mercurial a much easier transition...
Michael: Maybe Mercurial is easier, more intuitive, or something, and maybe in a parallel universe it had more luck and was adopted more widely - the thing is there's really only enough space for one "standard" DVCS, and it's pretty obvious that git became this standard DVCS.
Whatever advantages Mercurial might have over git don't seem big enough to make git users (who are in big majority) switch, and Mercurial and git compete for exactly the same niche.
Strong words, and for the most part you're right: Git has won the current DVCS popularity contest. You're railing against a minority that knows it's a minority that probably do work on projects for which you have no interest in hg. There are loads more projects using Git than Mercurial. Fact. But how much of a hassle is it for the git aficionado to check out a project in hg compared to bazaar or older projects in Subversion or CVS or any other holdout VCS? Are there exorbitant disk usage demands from Git/Hg that require that only one of the two is installed on a system at a time?
This is like posting that Ruby must die because Python is much more popular. Multiple approaches with highly overlapping goals and functionality, but each ecosystem has its pros and cons, its personalities and packages. I'm highly dubious that Django or RoR would be better off if the other didn't exist.
You also seem to ignore the fact that it is possible to be proficient in MORE THAN ONE TOOL for the similar functions. I can do Git, I can do Mercurial, I know the differences and I am better off for understanding the ins and outs of both. I can also use LaTeX and OpenOffice. I prefer the quality typography and simplicity of the former to the latter, but if I'm drafting a document where I am going to be emailing it to colleagues with track changes turned on, I'm going with an OO document. I prefer vim as my code editor, but on a system I don't administer I'll make do with Textmate or Emacs or whatever. Annoying, but not the end of the world.
The people at Github have actually done a pretty good job on Hg/Git interop so far: http://hg-git.github.com/ -- it's worked for me fine the few times I've tried it, though I do fall back to using git natively on the projects that are in git about 95% of the time.
Screw "there must only be one way to do it"; though the niches are similar they are not identical, and the fact that the basic command line semantics of hg are barely modified verbs from SVN, which are barely modified verbs from CVS make it a pretty natural migration path for people who want to get familiar with a DVCS with a minimum of barrier to entry in terms of learning. In fact, on the subject of dead VCSses, what happens after the world standardizes on Git? In 5 years some new paradigm for revision control may come along and the shuffle will repeat itself.
It's a lot easier to migrate a non-developer user from backwards tools like Visual SourceSafe to vanilla Mercurial or TortoiseHg than it is to Git/Tortoisegit. Not all people contributing to software are developers who love tweaking knobs. Until there's a Git-lite that is simpler to deal with for casual users who want to submit tests, sample data, etc to a project, I'm going to continue to advocate Mercurial.
I used and loved Git and (especially) Github when I was developing on a Mac.
Git on Windows seems to be another story though. Perhaps things have improved since I last checked, but it looked far from polished and it seems Mercurial does the cross-platform thing rather more easily.
So my old Ruby projects live still on Github and my new Python projects are on Bitbucket. That's no biggie - and at least I can re-use the project names!
taw, here's a factor you might not have considered: Once a technology reaches a certain maturity level, the rate of revolutionary technological progress approaches zero despite the visible inferiority of the status quo. QWERTY keyboards, HTML, C based languages & WIMP for example.
The VCS ecosystem is right on the cusp of making that shift which means we may possibly be stuck with git for the next 10,000 years. Keeping Mecurial in contention could be just the push necessary to destabilize the market enough that the next revolutionary CVS system will break through, the same way the CVS/SVN wars let git through.
The short term pain of dealing with both git & mercurial is balanced out by not having to use something as sucky as git for the next 10,000 years.
There's a certain merit in the philosophy of always biasing towards anarchy as much as possible to forstall the inevitably technological stagnation.
Xianhang Zhang: It's funny that you say it but:
* I use Dvorak keyboard. Interoperability isn't terribly important here.
* HTML is an extremely fast evolving technology, it grew from a bunch of static websites with text to hundreds of billions of pages and millions of web applications of all sorts. It's really remarkable. And it was only possible because of a single base technology. If there were 10 vendor specific technologies, like Java, Flash, ActiveX, and whatnot, and websites actually had to use them - we would probably still not have Gmail and blogs.
* Vaguely C-syntax languages evolved a lot. Javascript in particular is so far beyond what C can do, it seems that C syntax does little harm.
* None of alternatives to WIMP seem to work much better, but if you want to you can use an iPhone.
So if git is to be the one DVCS to rule them all, does that mean that no other future DVCS projects should be started either?
If so, that seems to be dooming DVCS to eventual stagnation as git becomes the new CVS.
Either that or we end up with endless market segmentation as some new project with new idea X would need to brand itself as "no we're not really a DVCS, we're an XDVCS".
And then we're back to square one as a bunch of new XDVCS projects start up to compete in the new "space".
Friendly competition and cross pollenation between open source projects is vital to their ongoing development.
If all gits competitors died, then that would be the start of gits own lingering decline.
I think this: http://hg-git.github.com/ solves the interaction problem :-)
Mr. Stone: It does not, bridges like that only introduce lowest common denominator functionality. (And if it's anything like git-svn it's also horribly fragile and slow.)
All I have to say for you is... a big fuck you. I personally prefer git and use it daily, I also like Mercurial and I've also worked on some projects that were using Bazaar. A project must not be sentenced to death just because a dumb fuck like you can't think outside the box. People like you should be stripped of the free speech right. Have a great day in your cave.
Robert
Following this argument, Linux/MacOS etc should also die due to popularity of Windows in the desktop world.
Monocultures are never a good idea.
@Jason Scheirer
@Xianhang Zhang
I'd say the command table on the WikiVS page for git and Mercurial says it all. Mercurial tends to require much more convoluted commands for the stuff git does naturally (and the table doesn't even LIST a Mercurial equivalent for "git commit" without the "-a")... probably because, like Subversion did with CVS, Mercurial kept command familiarity to its detriment.
In my opinion, much better to rip the band-aid off quickly and switch to a VCS that has unfamiliar yet more useful commands. (And keep in mind, I'm a big believer in Python everywhere it's efficient enough, so if I prefer a VCS written in C, Perl, and Shell to one written in Python, that says a lot)
As I see it, Git's command structure is superior once you get used to it, regardless of the underlying implementation of said command structure.
Git isn't a protocol and comparing http to git is like comparing FileZilla to ftp and Internet Explorer to http.
They both use the protocols but they are not a protocol.
Why should a product simply give up trying to evolve because another is classed as the best.
How did git manage to get where it is today if it didn't evolve...
If products don't have some sort of competition improvements slow down, new features are not written. Look at the browser market for as a good example. Microsoft have been forced kicking and screaming to compete with Chrome and Firefox now but before Google release Chrome... IE was market share by a long shot and HTML5 was a pipe dream.
If hg is not a good product it will end up dead or in use by a limited bunch of developers who find it to their preference. Can you name me one critical flaw in hg that should stop someone using it? other than git is the standard (don't use anything else).
Absolutely bizarre rant. I prefer X over Y, so I hope Y goes away. Like others have stated, you must also want Linux gone, Ruby gone, and only drink Budweiser.
Anonymous: Version control systems are protocols, and protocols are winner take all. Having 100 version control systems makes as much sense as having 100 incompatible replacements for HTTP.
Fortunately I ended up being right, and git is currently the only one left standing.
When you have only one left standing, all is lost. I like Git and I like Mercurial, hell sometimes I even like ClearCase and SVN.
And no, it's not a protocol. You want it to be but it's not and thank god it's not. Now developers can pick and choose what works for them.
P.S. I enjoy your blog, not a personal "attack" in any way. I just feel like everything has it's place.
> Fortunately I ended up being right, and git is currently the only one left standing.
Are you sure? It's end of 2015 now and hg is doing fine. As a hg user, I can push and pull from git repos losslessly using hg :)
Anonymous: Fortunately I was completely right with this post and git completely dominated and by now non-git version controls have about as much relevance as NetBSD in operating systems.
Dear Mr. T-aw(strich),
just burying your head in the sand doesn't make something go away. Mercurial is a still doing great and Gitlab is even working with octobus to provide hg support. I'm glad Opensource community does not think in the narrow confines like you. We are not MS/Apple monopoly who would go to any extreme to kill competition. We live and thrive in a rich diverse environment and enjoy the success of other open source projects. Also having more tools doesn't confuse us, It just means we have another choice to make. Just like we made when we chose a distro, then a DE, then a language, then an editor and so on, we also can make a choice of DVCS based on the needs of the project. Maybe you're a windows/mac user who never had those choices.Well in that case you'd be better off using a closed source DVCS too.
This article was stuck with me since you first wrote it. I thought you were right then and I am pleased to see that you were right. Git won, and those others have faded into complete obscurity.
The article currently ends like this:
> we need a second DVCS as much as we need a second character set, or a second .
what was the last word supposed to be?
Yeah, I was really right on this one, it's no longer a controversial take, Mercurial and such are all long dead.
> what was the last word supposed to be?
I wrote it in 2010, so I don't remember what I was trying to use as an example that got lost in editing.
I have decided that you left it out intentionally, to be supplied by the mind of the reader.
In my mind it is “ass”.
Post a Comment