[nnq]

Since everybody is always repeating it and one can take Git being the "winner" of the DVCS "war" as a fact, I just have to ask: why tf did Git win at this?

...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages (yeah, they make sense after you dive into the docs to search for the thing mentioned in the message or you google for it, but that's not how it should be) ...and for anything more complicated you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho ...it's a great tool but at the same time utterly nightmarish if you stop to think about it instead if just using it on auto-pilot

[lobster_johnson]

> and for anything more complicated you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho

Actually, I think you are perfectly wrong about that "sin". You just hit upon the exact reason why Git is good.

Git's point is that the data model is the tool. There is no abstraction (or at least very few), because it would only serve to camouflage what is important about it. It's just a data model and tools to manipulate it.

The way to explain Git is to start with the database: blobs, commits, references, and so on. The neat thing is that the way Git implements version control -- that is, linear version control (there are exceptions, like Darcs) -- is how version control must necessarily work.

In other words, if you understand Git, you understand how version control, and vice versa.

Of course you can have a VCS that is a completely black box. But even a black box needs a sort of public data model that the user understands ("files", "versions", "branches"), and I think Git's transparent, open-engine-approach is better than any other approach so far. For one, it makes it really extensible.

(I used to be a Darcs user, which requires that you become a quantum phycisist to understand its data model. I loved Darcs, but it meant that it broke, and it often did, it was almost impossible to fix the problem by hand.)

Now, I absolutely admit that Git's UI is terrible. It's geared towards hard-core developers who work on things like the Linux kernel. There little middle ground between the easy and the hard, and the learning curve is steep. But this is the fault of the command-line tools, and my thesis applies regardless of the UI.

Git has gotten better over the years. Just the fact that a newly created branch now has a default origin branch (so you don't have to set up the two .gitconfig keys you would need manually) is an amazing usability improvement that should have existed from the start.

[pnathan]

I have used hg for about four years now and have basically transitioned over to git. It's hard to explain why, exactly. Yes, network effect, but it's more: it's like git integrated deeply into the underlying model rather than trying to abstract over the model.

I would call myself a power user - I am the clearcase->hg transition guy in what I do, I've designed/maintained an enterprise hg extension (guestrepos, look 'em up, they are amazing), use mq, etc. But I think that the fundamental win for git is that they don't abstract, and this allows clearer understanding of what is happening when things go pear-shaped.

But, that's my opinion. I use both on a daily basis.

[ezquerra]

TortoiseHg developer here (i.e. I'm probably biased, take my comments with a grain of salt, yada, yada, yada...).

We discussed this a bit on the last mercurial sprint.

In jest, someone said that a lot of git users have what they'd call a "Helsinki syndrome". Probably that is not very far from the mark.

I think that what git brings in functionality is good enough (specially compared to non DVCSs) to make people want to use it and put the effort to understand it. On the other hand it is hard enough to use that when people finally manage to wrap their heads around it they are so proud that they must tell everybody about it.

It is actually quite brilliant if you think about it: Make a SW that does something really well, better than most other similar tools, but wrap it in a horrible UI to keep your users on their toes and make them proud that they are able to use it! This starts an incredible self-congratulatory feedback effect which gives notoriety to your tool.

If you add to that the fact that git was created by one of the most famous hackers of all time, plus the creation of GitHub, and then you get the perfect storm to make git the open-source tool of choice.

Mercurial on the other hand is just as useful (if not more) than git, but it is just not as hard to use. People use it, like it, but they do not need to feel proud about it. It is just easy. There is no need to talk about database details, reflogs, etc. There is no need to blog about it. It just works. This should be great and make mercurial the better tool but it has the perverse effect of not making it cool to talk about it. There is no challenge, there is no achievement in learning how to use mercurial. This makes it hard to get the same sort of buzz that you get from a tool such as git.

In my opinion it is a little surprising that such a knowledgeable bunch such as the Hacker News readers and the open source contributors in general are not able to evaluate both tools just in their technical merits and instead follow the buzz. Understandable, but surprising nonetheless.

[laureny]

> ...I use it every day, but if I try to look at it from the outside it's an UX horror: weird terminology with worst possible choice of words, inconsistent terminology even in the docs, inconsistent argument naming, mostly incomprehensible error messages

If a tool makes you productive, you make the effort to look beyond its flaws.

Windows and git are just two examples.

[nnq]

funny way of putting them together :) ...especially since Git is UNIXy to the bone, in all the bad ways.

[mercurial]

I was thinking about the other day, and I disagree. The main beef I have with git is that it's NOT UNIXy enough. Instead of having one command for one thing, it has one command for several different things (eg, git checkout) which I find absolutely aggravating.

[eridius]

Why do developers love *nix systems? Git and unix have a lot of parallels, especially in that git tries to embrace the unix philosophy of having lots of little tools that work with each other instead of one monolithic binary.

[rimantas]

  > why tf did Git win at this?

I was giving a presentation few years ago when SVN vas still a king and hg and git were only emerging (I included bazaar too in that presentation). Even then I recommended to pick up git. I don't remeber giving any really solid reasons, it was more like a hunche, but now when you asked. I'd say git just does make sense at some deeper level. Whe foundation is very sound you can fix bad UX later, but when foundation is no so good, you will suffer endlessly.

[cpeterso]

Wikipedia has an interesting table comparing the command names used by various version control systems. Unsurprisingly, git makes up new names and reuses other names in new contexts. :)

https://en.wikipedia.org/wiki/Comparison_of_revision_control...