8 ms·

Mercurial over Git

38 points by jchonphoenix 17y ago

lincolnq 17y ago
Your use of the words "intuitive" and "revert" in this context betray that your models are driven by how you expect centralized version control to work. While Git and Mercurial are nearly isomorphic in implementation, their UIs differ significantly because they're written with different models of DVCS in mind. Basically, I would argue you haven't fully grokked Git. To the extent that I have understood Git's model, I have found it extremely insightful; if you want this insight, you should spend a little more time trying to understand it before giving up on it.
- alexgartrell 17y ago
  As a long-time TA for the class leading up to 15-410 (almost as long as he's been a student at CMU) I can firmly attest to the fact that we have done absolutely nothing to make him aware of centralized version control (or distributed version control...) :) So basically, he's got the freshest possible eyes to make this judgement, and if your counterclaim is that he hasn't truly grokked it yet, then that suggests that it may be counterintuitive. Additional fairness: the project in question is a 6-week round-the-clock code fest. Writing a kernel from scratch takes forever. (Is this project just a waste of time? Having moved on to poking at the Linux kernel and stuff, I'd say almost certainly, but that's a topic for another conversation.) Most Sincerely, Alex "Found out the hard way that reset != revert" Gartrell
  - theli0nheart 17y ago
    > if your counterclaim is that he hasn't truly grokked it yet, then that suggests that it may be counterintuitive. Or proper usage wasn't explained to him correctly.
    - wmcc 17y ago
      Since we learn from the online docs, doesn't your statement imply that Gits online documentation isn't very good?
      - pyre 17y ago
        > Since we learn from the online docs That's an assumption.
        mcn 17y ago
        wmcc stated he was in the same OS class as the blog poster.
  - jshen 17y ago
    " if your counterclaim is that he hasn't truly grokked it yet, then that suggests that it may be counterintuitive." You should say, "it may be counterintuitive to him". Intuition is based on past experiences and our internal metaphors. We have no reason to believe that his "intuition" is the same as most of the population that would use git.
- blasdel 17y ago
  git is the first revision control system I've used where "revert" actually does what I "intuitively" expect it to: begin a new commit that reverts a commit in the history. The rest of the clown-car VCSes use "revert" to go back in time to that commit in the history.
  - tghw 17y ago
    Clearly, you don't know your clown-cars. Mercurial uses hg backout to start a new commit that backs out a previous commit, hg rollback to undo the previous transaction (without a separate commit), and hg revert does undoes the uncommitted changes in your working directory, very similar to MS Word's (now defunct) and Photoshop's (still active) File > Revert command. To me, revert means "revert all my changes to the last saved version", which is exactly what Hg does.
    - blasdel 17y ago
      I had another sentence in my post that I edited out that was a caveat to Mercurial: at least it's possible to get the 'git revert' behavior with hg without implementing it yourself from a patch-series dump. To me, revert means "stage a new commit that reverts this commit in the history as if it never existed". When I first used svn, I really expected 'revert' to mean "revert this commit". I also 'intuitively' expected it to have something like git's index, and ended up just working around that by just laboriously creating my own set of patches to feed it in another checkout. Not everyone's mental models line up — we are both free to consider one another as a moron (see also: politics, religion).
icefox 17y ago
"Need to make a new branch? Try git branch--er... I mean 4 seemingly random Git commands that don't include the word branch. " 'git branch <branchname> [start-point]' creates a new branch.... Maybe he is referring to the fact that git branch wont change change branches? You have to use git checkout to actually switch branches. "Not only is documentation for some important features sparse, the documentation that does exist is rarely ever of the best quality." I am curious what specifically he was referring to. The docs on git-scm are pretty extensive. Between the docs, books, cheatsheets, videos there is a ton out there. Even the man pages include example usage where many man pages for command line tools do not. Something I can't help but ponder is that in switching to the second system they already had a grasp of some dvc concepts making it easier and if trying git second would have been easier.
- viraptor 17y ago
  I think he meant `git checkout -b ...` since that's what people want to do most of the time. What's the use case for creating a branch if you're not going to use it straight away? (and no 'branch' in the command really)
  - jshen 17y ago
    does he really have a problem remembering 'git checkout -b ...'? Seems like a non issue to me.
    - viraptor 17y ago
      It's not an issue, but it can be an annoyance. Put many of them together and you've got a reason why projects like Ubuntu's 100 papercuts exist. If you have to work with something that just isn't quite right even if it works in the end, it can affect your work.
  - hannibalhorn 17y ago
    I always branch before rebasing. Especially when cleaning up history (merging 5-6 "checkpoint" type commits for a big feature into one, etc.) It makes it easy to get back to where you started and you have the original work for reference purposes.
OSTwister 17y ago
If I understand git right, it's designed to allow different front ends - the "porcelain." I wonder if an alternative "porcelain" could be made which would be more intuitive to some?
- lincolnq 17y ago
  It was made several years ago, near the birth of Git, called cogito. http://git.or.cz/cogito/ http://git.or.cz/cogito/ . It's currently deprecated. It was how I learned Git actually; it made the UI very similar to mercurial's UI. It was actually a surprisingly good learning curve, because it allowed me to experiment with git commands side-by-side with cg commands on the same repo, and I slowly transitioned out of cg into full-fledged git, almost without noticing. I'm a little sad it's not maintained.
  - OSTwister 17y ago
    Very like Mercurial eh? I wonder if it'd be worth someone's while to pick it up & maintain it.
- viraptor 17y ago
  That thought has been in my mind for some time... maybe one day I'll actually get annoyed enough to write a nice wrapper. Where nice is subjective and == like svn and mercurial, with sane defaults (so no options are needed most of the time) and completely redesigned 'remote'.
- j_baker 17y ago
  That's a goal for eg: http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/
  - Goosey 17y ago
    I just read the 'intro' presentation ( http://people.gnome.org/~newren/eg/presentations/git-introduction.pdf http://people.gnome.org/~newren/eg/presentations/git-introdu... ) and I have to say I am really excited to try easygit out. It stays very similar to the way git operates, but it seems to make the default actions far more logical to me. Even as someone who has spent time trying to 'master' git really appreciate this effort.
pkulak 17y ago
You don't have a personal preference, you're just ignorant. Okay, now no one has to comment anymore; I've taken care of all of it.
- wmcc 17y ago
  Troll
jmtulloss 17y ago
It will be interesting to hear what he thinks of Mercurial after running into some of its warts. I think it's valuable to read the opinions of people who are just getting into this game. Those of us with lots of experience with the everyday tools of the trade might not see a lot of substance to this critique, but it's important when designing any product to make sure it's approachable for novices. There's often a tradeoff there for power or flexibility, which git has been unwilling to make (probably rightfully so), but it does seem that things could be done to make the tool easier to get into, without necessarily compromising its power.
- tghw 17y ago
  It's not a trade-off of power or flexibility as much as it is a difference in priorities. Git puts all of the powerful -- and potentially dangerous -- tools front and center (history editing, to name a big one), whereas Mercurial supports all of the same functionality, but hides away some of the more dangerous tools until you're ready to enable them.
drewcrawford 17y ago
To a lot of the people who prefer Hg to Git, I ask this question: What's the proper way to do a feature branch in Hg? (serious question) The three answers I've heard are: * Use hg branch <branchname> like git. The problem is this always requires me to do a push -f, which doesn't feel right... * Use clone. Really? For a feature branch? * Use the LocalBranches extension. Really, feature branches (the #1 productivity gain since switching to DVCS) isn't in the core code? I have yet to find an equivalent to what I consider a core git workflow.
- stevelosh 17y ago
  You could use bookmarks if it's just going to be a local branch that only you work on, and you don't want anyone else to see the branch name. I'd probably use a named branch. Yes, you have to use push -f the first time you push that branch to a remote repo, but I think of that as a "hey, do you really want other people to see this work-in-progress branch?" safeguard.
- reiddraper 17y ago
  push -f is what I use, "force" makes it sound more sinister than it is.
  - samps 17y ago
    push -f is the thing. Requiring -f just makes you think twice before accidentally exposing the rest of the world to your changes without merging them.
- j_baker 17y ago
  Hg allows local branches natively, but it tends to prefer pushing from repository to repository rather than from local branch to local branch. So you can do it either way 1 or 2 (whatever suits you). It sounds like #3 might be based on outdated information.
MrMatt 17y ago
This seems to be less about Mercurial vs Git, and more Jon Chu vs Git. Although I haven't used Mercurial, all of the issues he brings up I found really easy to solve when I started using Git (~2 years ago). The number and quality of online resources has only improved since then.
awt 17y ago
Grb gives you wings: http://grb.rubyforge.org/ http://grb.rubyforge.org/
- jkmcf 17y ago
  grb will help you create and manage remote branches. Why something like this isn't baked into git, I don't know. I'm just happy grb exists! git_remote_branch version 0.3.0 Usage: grb create branch_name [origin_server] grb publish branch_name [origin_server] grb rename branch_name [origin_server] grb delete branch_name [origin_server] grb track branch_name [origin_server] There are also plenty of aliases for the various actions. create: create, new delete: delete, destroy, kill, remove, rm publish: publish, remotize, share rename: rename, rn, mv, move track: track, follow, grab, fetch
jchonphoenix 17y ago
I believe the preference of one system over the other is based mostly on how they feel to the user. Git is like a swiss army knife. git checkout can do just about everything and anything. Mercurial seems to be more split. hg update and hg revert do separate things. Again a lot of preference comes down to personal feel. I prefer modularity. Others may prefer one tool solving it all.
- tghw 17y ago
  Apropos of your comment (and possibly the source): http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ http://stevelosh.com/blog/2010/01/the-real-difference-betwee...

38 points by jchonphoenix 17y ago

Your use of the words "intuitive" and "revert" in this context betray that your models are driven by how you expect centralized version control to work. While Git and Mercurial are nearly isomorphic in implementation, their UIs differ significantly because they're written with different models of DVCS in mind. Basically, I would argue you haven't fully grokked Git. To the extent that I have understood Git's model, I have found it extremely insightful; if you want this insight, you should spend a little more time trying to understand it before giving up on it.

alexgartrell 17y ago
As a long-time TA for the class leading up to 15-410 (almost as long as he's been a student at CMU) I can firmly attest to the fact that we have done absolutely nothing to make him aware of centralized version control (or distributed version control...) :) So basically, he's got the freshest possible eyes to make this judgement, and if your counterclaim is that he hasn't truly grokked it yet, then that suggests that it may be counterintuitive. Additional fairness: the project in question is a 6-week round-the-clock code fest. Writing a kernel from scratch takes forever. (Is this project just a waste of time? Having moved on to poking at the Linux kernel and stuff, I'd say almost certainly, but that's a topic for another conversation.) Most Sincerely, Alex "Found out the hard way that reset != revert" Gartrell
- theli0nheart 17y ago
  > if your counterclaim is that he hasn't truly grokked it yet, then that suggests that it may be counterintuitive. Or proper usage wasn't explained to him correctly.
  - wmcc 17y ago
    Since we learn from the online docs, doesn't your statement imply that Gits online documentation isn't very good?
    - pyre 17y ago
      > Since we learn from the online docs That's an assumption.
      - mcn 17y ago
        wmcc stated he was in the same OS class as the blog poster.
- jshen 17y ago
  " if your counterclaim is that he hasn't truly grokked it yet, then that suggests that it may be counterintuitive." You should say, "it may be counterintuitive to him". Intuition is based on past experiences and our internal metaphors. We have no reason to believe that his "intuition" is the same as most of the population that would use git.
blasdel 17y ago
git is the first revision control system I've used where "revert" actually does what I "intuitively" expect it to: begin a new commit that reverts a commit in the history. The rest of the clown-car VCSes use "revert" to go back in time to that commit in the history.
- tghw 17y ago
  Clearly, you don't know your clown-cars. Mercurial uses hg backout to start a new commit that backs out a previous commit, hg rollback to undo the previous transaction (without a separate commit), and hg revert does undoes the uncommitted changes in your working directory, very similar to MS Word's (now defunct) and Photoshop's (still active) File > Revert command. To me, revert means "revert all my changes to the last saved version", which is exactly what Hg does.
  - blasdel 17y ago
    I had another sentence in my post that I edited out that was a caveat to Mercurial: at least it's possible to get the 'git revert' behavior with hg without implementing it yourself from a patch-series dump. To me, revert means "stage a new commit that reverts this commit in the history as if it never existed". When I first used svn, I really expected 'revert' to mean "revert this commit". I also 'intuitively' expected it to have something like git's index, and ended up just working around that by just laboriously creating my own set of patches to feed it in another checkout. Not everyone's mental models line up — we are both free to consider one another as a moron (see also: politics, religion).

icefox 17y ago

"Need to make a new branch? Try git branch--er... I mean 4 seemingly random Git commands that don't include the word branch. " 'git branch <branchname> [start-point]' creates a new branch.... Maybe he is referring to the fact that git branch wont change change branches? You have to use git checkout to actually switch branches. "Not only is documentation for some important features sparse, the documentation that does exist is rarely ever of the best quality." I am curious what specifically he was referring to. The docs on git-scm are pretty extensive. Between the docs, books, cheatsheets, videos there is a ton out there. Even the man pages include example usage where many man pages for command line tools do not. Something I can't help but ponder is that in switching to the second system they already had a grasp of some dvc concepts making it easier and if trying git second would have been easier.

viraptor 17y ago
I think he meant `git checkout -b ...` since that's what people want to do most of the time. What's the use case for creating a branch if you're not going to use it straight away? (and no 'branch' in the command really)
- jshen 17y ago
  does he really have a problem remembering 'git checkout -b ...'? Seems like a non issue to me.
  - viraptor 17y ago
    It's not an issue, but it can be an annoyance. Put many of them together and you've got a reason why projects like Ubuntu's 100 papercuts exist. If you have to work with something that just isn't quite right even if it works in the end, it can affect your work.
- hannibalhorn 17y ago
  I always branch before rebasing. Especially when cleaning up history (merging 5-6 "checkpoint" type commits for a big feature into one, etc.) It makes it easy to get back to where you started and you have the original work for reference purposes.

OSTwister 17y ago

If I understand git right, it's designed to allow different front ends - the "porcelain." I wonder if an alternative "porcelain" could be made which would be more intuitive to some?

lincolnq 17y ago
It was made several years ago, near the birth of Git, called cogito. http://git.or.cz/cogito/ http://git.or.cz/cogito/ . It's currently deprecated. It was how I learned Git actually; it made the UI very similar to mercurial's UI. It was actually a surprisingly good learning curve, because it allowed me to experiment with git commands side-by-side with cg commands on the same repo, and I slowly transitioned out of cg into full-fledged git, almost without noticing. I'm a little sad it's not maintained.
- OSTwister 17y ago
  Very like Mercurial eh? I wonder if it'd be worth someone's while to pick it up & maintain it.
viraptor 17y ago
That thought has been in my mind for some time... maybe one day I'll actually get annoyed enough to write a nice wrapper. Where nice is subjective and == like svn and mercurial, with sane defaults (so no options are needed most of the time) and completely redesigned 'remote'.
j_baker 17y ago
That's a goal for eg: http://people.gnome.org/~newren/eg/ http://people.gnome.org/~newren/eg/
- Goosey 17y ago
  I just read the 'intro' presentation ( http://people.gnome.org/~newren/eg/presentations/git-introduction.pdf http://people.gnome.org/~newren/eg/presentations/git-introdu... ) and I have to say I am really excited to try easygit out. It stays very similar to the way git operates, but it seems to make the default actions far more logical to me. Even as someone who has spent time trying to 'master' git really appreciate this effort.

pkulak 17y ago

You don't have a personal preference, you're just ignorant. Okay, now no one has to comment anymore; I've taken care of all of it.

wmcc 17y ago
Troll

jmtulloss 17y ago

It will be interesting to hear what he thinks of Mercurial after running into some of its warts. I think it's valuable to read the opinions of people who are just getting into this game. Those of us with lots of experience with the everyday tools of the trade might not see a lot of substance to this critique, but it's important when designing any product to make sure it's approachable for novices. There's often a tradeoff there for power or flexibility, which git has been unwilling to make (probably rightfully so), but it does seem that things could be done to make the tool easier to get into, without necessarily compromising its power.

tghw 17y ago
It's not a trade-off of power or flexibility as much as it is a difference in priorities. Git puts all of the powerful -- and potentially dangerous -- tools front and center (history editing, to name a big one), whereas Mercurial supports all of the same functionality, but hides away some of the more dangerous tools until you're ready to enable them.

drewcrawford 17y ago

To a lot of the people who prefer Hg to Git, I ask this question: What's the proper way to do a feature branch in Hg? (serious question) The three answers I've heard are: * Use hg branch <branchname> like git. The problem is this always requires me to do a push -f, which doesn't feel right... * Use clone. Really? For a feature branch? * Use the LocalBranches extension. Really, feature branches (the #1 productivity gain since switching to DVCS) isn't in the core code? I have yet to find an equivalent to what I consider a core git workflow.

stevelosh 17y ago
You could use bookmarks if it's just going to be a local branch that only you work on, and you don't want anyone else to see the branch name. I'd probably use a named branch. Yes, you have to use push -f the first time you push that branch to a remote repo, but I think of that as a "hey, do you really want other people to see this work-in-progress branch?" safeguard.
reiddraper 17y ago
push -f is what I use, "force" makes it sound more sinister than it is.
- samps 17y ago
  push -f is the thing. Requiring -f just makes you think twice before accidentally exposing the rest of the world to your changes without merging them.
j_baker 17y ago
Hg allows local branches natively, but it tends to prefer pushing from repository to repository rather than from local branch to local branch. So you can do it either way 1 or 2 (whatever suits you). It sounds like #3 might be based on outdated information.

MrMatt 17y ago

This seems to be less about Mercurial vs Git, and more Jon Chu vs Git. Although I haven't used Mercurial, all of the issues he brings up I found really easy to solve when I started using Git (~2 years ago). The number and quality of online resources has only improved since then.

awt 17y ago

Grb gives you wings: http://grb.rubyforge.org/ http://grb.rubyforge.org/

jkmcf 17y ago
grb will help you create and manage remote branches. Why something like this isn't baked into git, I don't know. I'm just happy grb exists! git_remote_branch version 0.3.0 Usage: grb create branch_name [origin_server] grb publish branch_name [origin_server] grb rename branch_name [origin_server] grb delete branch_name [origin_server] grb track branch_name [origin_server] There are also plenty of aliases for the various actions. create: create, new delete: delete, destroy, kill, remove, rm publish: publish, remotize, share rename: rename, rn, mv, move track: track, follow, grab, fetch

jchonphoenix 17y ago

I believe the preference of one system over the other is based mostly on how they feel to the user. Git is like a swiss army knife. git checkout can do just about everything and anything. Mercurial seems to be more split. hg update and hg revert do separate things. Again a lot of preference comes down to personal feel. I prefer modularity. Others may prefer one tool solving it all.

tghw 17y ago
Apropos of your comment (and possibly the source): http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ http://stevelosh.com/blog/2010/01/the-real-difference-betwee...