18 ms·

> 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

> 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 7y ago
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?
- dllthomas 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        "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.
- js2 7y ago
  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 7y ago
    That sounds a lot like the patch theory stuff from darcs and pijul.
rjzzleep 7y ago
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 7y ago
  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 7y ago
  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=info https://www.mercurial-scm.org/wiki/RecordExtension?action=in... [2] https://www.mercurial-scm.org/wiki/CrecordExtension?action=info https://www.mercurial-scm.org/wiki/CrecordExtension?action=i...
- fanf2 7y ago
  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!
bunderbunder 7y ago
> 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.
- JohnFen 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
I dunno, I recently switched from ~4 years of using git to mercurial, and I am finding mercurial massively easier to use.
erik_seaberg 7y ago
I tried learning hg and arrived at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ 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?
jzoch 7y ago
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
marssaxman 7y ago
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.

fouronnes3 7y ago

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?

dllthomas 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        "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.
js2 7y ago
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 7y ago
  That sounds a lot like the patch theory stuff from darcs and pijul.

rjzzleep 7y ago

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 7y ago
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 7y ago
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=info https://www.mercurial-scm.org/wiki/RecordExtension?action=in... [2] https://www.mercurial-scm.org/wiki/CrecordExtension?action=info https://www.mercurial-scm.org/wiki/CrecordExtension?action=i...
fanf2 7y ago
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!

bunderbunder 7y ago

> 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.

JohnFen 7y ago
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 7y ago
  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 7y ago
    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 7y ago

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

erik_seaberg 7y ago

I tried learning hg and arrived at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ 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?

jzoch 7y ago

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

marssaxman 7y ago

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.