[andrewla]

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable.

I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands.

But in the end it's deceptive; git, ugly as it is, reflects the underlying data model. Once you understand that data model, and how the basic commands manipulate that model, then it becomes a very natural language for manipulating the commit chain.

If there's a downside, it's that git doesn't let you get away for too long without learning the data model, while Mercurial lets you live in blessed ignorance until the first time it doesn't work like svn does, and then you're stuck because its data model is not as cleanly exposed, so you need to gently massage it into a good state rather than just surgically moving it to where you want it to be.

[fouronnes3]

Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?

[js2]

re)use re)recorded re)solution.

It allows git to record and re-use how merge conflicts are resolved. It's an esoteric command that 9/10 users will probably never use. But if part of your day job is, say, merging your startup's[1] local development with that of an upstream project[2], you will come to love this command very very quickly.

1) Rockmelt; 2) Chromium.

[yepguy]

That sounds a lot like the patch theory stuff from darcs and pijul.

[dllthomas]

You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.

[jchw]

I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX.

The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes...

That’s why the site this post is about exists. If you don’t know about reflog, you are severely disadvantaged... and many of my coworkers at my previous employer certainly did not.

[dllthomas]

I guess I'm arguing that UX extends beyond command names and learning curves (while definitely incorporating those things). I'm on-board with the notion that there are aspects of git's UX that are terrible. But as a user, if your experience was awful, you would not love the software.

[jchw]

I mean, once you’ve gotten used to a given interface over years and years of practice, it’s obviously going to be a better experience for you. I practically have Git muscle memory at this point, to the point where I frequently type Git commands in Mercurial repositories.

I guess the real point is, just because we, who are experienced with Git, now have a good experience with Git, does that mean Git UX is good? I’d argue no. Bad UX doesn’t usually make software unusable or even unproductive necessarily, in my experience it usually means something more along the lines of, it’s unintuitive and confusing, and takes much more time to learn.

A good example would be something like Blender, especially pre-2.8. Is it bad? No! It’s good software. Is it good from a UX perspective? Well, it has unfamiliar paradigms and it tends to confuse people, so I would say no, and that’s why they’re trying to improve it.

In fairness, Git has done many small things over the years to improve its user experience and to reduce instances of data loss. But Facebook’s chistedit vs rebase -i is a pretty great example of UX differences imo. Git could catch up easily in some of these aspects.

[dllthomas]

"It takes more time to learn" is an important aspect of UX, and as I've said there are clearly ways in which the git UX can be improved.

But having said that, I really feel like the experience of expert users also matters and is often overlooked in discussions of UX. And I just don't think people love software when their experience using it is terrible.

[jzoch]

I've heard this repeated a lot but honestly find it very untrue. I understand git internals and watched half a dozen talks on hit but still have to Google how to split a commit in two or how to safely rebase vs merge when I'm dealing with too many conflicts in my rebases. How to accept their or my commits during a merge or rebase so I can skip conflict resolution, how to do X or Y. It's just bad UX. It's okay! I don't blame the tool but repeating "it's fine if you understand how it works" doesn't help, it perpetuates the idea that this bad UX is somehow good

[bunderbunder]

> git, ugly as it is, reflects the underlying data model. Once you understand that data model...

This is, like, the very definition of bad/sloppy UX.

[darkpuma]

No, I strongly disagree. Exposing the datamodel can be part of an excellent user experience if your target audience are programmers, as is the case with git. Where git goes wrong is numerous commands that do numerous very different things if given different flags. That has nothing to do with the underlying datamodel being exposed; it's just sloppy planning and design. That part is terrible UX.

[JohnFen]

Perhaps, but speaking personally, that doesn't matter much to me. What matters to me is how much easier a tool makes my job, and of all the version control systems I've used, git is easily the winner.

[bunderbunder]

And I don't want to say that Git isn't an improvement over many other version control systems.

But, IMO, the real sea change there is the shift to a DVCS, and not Git's interface. Within the set of DVCS that I've used, I find Git to be easily the most difficult to understand and work with, and the one where I have to spend the most time reading and grokking abstruse explanations of the tool's implementation details in order to figure out how to deal with some edge case.

I don't think that I'm the only one. My sense is that people whose only DVCS is git are much more likely to love it unconditionally than people who came to git after having first spent significant time on some other DVCS. For my part, as another concrete example, I have to spend a lot more time helping junior devs with source control snafus now that I'm at a Git shop than I did when I was at a Hg shop.

In summary, "Sure it's easy to use, you just have to read this lengthy explanation of its implementation details first," isn't really a compelling argument when you know that there are other competing products that are easy to use even if you didn't spend that much time on RTFM first.

[JohnFen]

Fair enough. I won't say git's UI is intuitive -- it's not. But once I crested the learning curve, I do prefer it over the alternatives I'm familiar with. When I need to do something unusual, I have better luck figuring out how with git than the others.

That said, I am not familiar with most of the various version control systems out there, and I could easily be missing something that's genuinely better.

[lalaithion]

I dunno, I recently switched from ~4 years of using git to mercurial, and I am finding mercurial massively easier to use.

[rjzzleep]

I don't get that argument at all. I came from svn, used cvs and ss and I think I even tried to use Perforce at some point.

I don't see how people consider mercurial "easier", "the winner" or whatever.

I think it's like languages: if you're a french speaker and you translate everything into your native tongue while learning, then of course you won't ever get past roman languages. It's just different.

`git add -p` is my absolute favorite command ever. `tig` is just awesome. The gui clients are so beautiful and take away all the so called uglyness nowadays, though I just can't find myself using anything over git add -p. Nothing in mercurials commandline ever came close to these two. But yeah tig isn't really part of git but at the same time it's been around for so long it might as well be.

[jcranmer]

The man page for git reset states in its first paragraph:

> In the first and second form, copy entries from <tree-ish> to the index. In the third form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match.

When your documentation starts by saying (in effect) "this command does several different things", that should be a very strong sign that your command UX has some issues.

[pseudalopex]

Mercurial had "hg record" since 2007[1] and "hg crecord" since 2008[2]. Now you would use "hg commit -i".

[1] https://www.mercurial-scm.org/wiki/RecordExtension?action=in...

[2] https://www.mercurial-scm.org/wiki/CrecordExtension?action=i...

[fanf2]

The Emacs magit status view has an even better version of git add -p: you can hit tab to expand and collapse diffs of files and hunks in the unstaged and staged changes, selectively s (stage) or u (unstage) everything or a file or a hunk. To split a hunk, highlight the relevant part with shift+arrows then hit s or u. It’s brilliant!

[erik_seaberg]

I tried learning hg and arrived at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... which is a crazy complicated answer to what should be the most important question.

There's just something about git branches and refs that makes sense to me. The CLI commands are a mess, of course—why can "reset" do everything?

[marssaxman]

It doesn't matter if you've learned git's data model or not; its use of terminology is inconsistent and confusing, and its command interface is disorganized and asymmetrical. In that way, I suppose it is very much like a "natural language", and not like the sorts of languages we are more accustomed to using when getting things done. Even if I know exactly what I want to do to the data structure git is managing, that doesn't help me find the commands I need to type to accomplish it. I have been using git for ten years now and I still have to rely on rote memorization of specific recipes in order to get anything done, which sucks because I am terrible at rote memorization.