9 ms·

Mercurial vs Git: Why Mercurial?

95 points by LeafStorm 15y ago

aninteger 15y ago
Regarding the "A Sane Command Line Interface" topic. Linus mentioned in his talk at Google about Git that he often chose the opposite approach to do things rather than follow the Subversion approach. This might be why the commands are not named the same as Subversion commands. git add/rm handles making changes to the index and there is no similar concept in mercurial or subversion.
- Argorak 15y ago
  I think this is not only about similarity. For example, branching works with `git branch foo`, but it doesn't immediately switch to that branch. If you want to do this, `git checkout -b foo` is the way to go. While this might make some sense if you understand the details behind git, it is horrible from a user interface perspective. I know a lot of people that didn't know about checkout -b because they never thought about looking there. Also, some features are half-implemented, for example `git add -p` which does not trigger on file-additions (and sometimes is broke out of the box on some distros). I like git, but the interface: not so much. Too many rough edges. The blog post does not illustrate this, though :/. Update: and for the downvotes, would you care to explain why?
  - weaksauce 15y ago
    I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout command switches between them. There is a convenience command that does a checkout and create. The main thrust of the checkout command is to change branches so if a branch does not exist they give you a convenience method to do so. edit: git add -p(atch) is supposed to create patches of existing files assuming that that is the most common use case. Use --interactive if you want to add new files and still do interactive patching.
    - Argorak 15y ago
      I am aware why the distinction exists - from the perspective of "git(1) manipulates the git file system", it make sense (as I wrote). But most people I know tend to use "branch" for all their branching work (as the name implies) and never bother about the finer details. But the fact that this sore point exists and is real makes the git UI problematic. I don't bother, because I know the details, but if I have to explain it to every new guy in the office, there is something wrong. About git add -p: yes, I am aware of -i, but it doesn't give you the easy "give me all changes to the file system and let me sign them off"-interaction that git add -p has. They are two completely different interaction modes.
      - weaksauce 15y ago
        git add -i 5<enter> *<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc... then <enter> gets you to the staging that you are used to. this will get you into the quick patch mode that -p does. -p is just a short circuit of this.
  - jacknagel 15y ago
    You might find `git add -N` ("--intent-to-add") useful. It's an extra step, yes, but it allows you to e.g. view the content of new files with `git diff` without actually staging the content for commit, and will allow you to stage that file during `git add -p`.
benatkin 15y ago
I like what's on the git part of the table better, and it isn't just familiarity with git but familiarity with unix. I'm glad that since I use git and git-svn, I don't have to type remove and move instead of rm and mv.
- LeafStorm 15y ago
  One thing the article misses is that hg also has a bunch of built-in aliases for a lot of these commands, including: * mv for move * rm for remove * co for clone (which SVN uses as an abbreviation for svn checkout) * ci for commit As well as the fact that you can abbreviate any command that hg doesn't have specific aliases defined for by typing any unambiguous prefix. Git, on the other hand, has no aliases by default, and no prefix aliases.
  - julian37 15y ago
    Come on, those are very minor quibbles. If you want aliases, it's literally a matter of five minutes to find some (e.g. [1] is the 4th hit for a google search for "git aliases") and put them into your .gitconfig. And I would argue that prefixes are more confusing than helpful, especially in conjunction with aliases. For instance, going by prefixes you'd expect "co" to mean commit, yet in hg/svn it means clone/checkout. [1] http://gitready.com/intermediate/2009/02/06/helpful-command-aliases.html http://gitready.com/intermediate/2009/02/06/helpful-command-...
  - buff-a 15y ago
    Gosh, I know. That's awful. Its much better that hg allows people to type hg mv, rather than forcing lazy people to modify the .bashrc file so that they can type "ga" instead of "git add". I mean, I know "hg mv" is actually longer than "ga", but by golly, expecting unix shell users to know about the alias system built into the operating system is just the kind of elitism we can expect from linus.
    - benatkin 15y ago
      I hate to burst your bubble, but git has alias support. http://githowto.com/aliases http://githowto.com/aliases
badboy 15y ago
It is a bad thing to have just one command to move files instead of 3? Nah, I don't get it. That git has different commands than svn is because it is different. Why should it adopt any of the commands if it does different things? When I started with git, I never ever destroyed any of the history. Because it's not easy to do so. I looking forward to read the follow-up article where he wants to point out some advantages of git.
NelsonMinar 15y ago
GitHub is the first and last reason to prefer Git to anything else. That community is so vital right now, it cements Git as the essential VCS. I could believe Mercurial is better in some ways than Git and I could even believe Atlassian's BitBucket service is in some theoretical sense better than GitHub. But most code is on GitHub, so git wins.
- rsanheim 15y ago
  This. Github is the killer app for dvcs. Both git and mercurial are good enough, and github simply makes it a no brainer.
  - bwarp 15y ago
    Apart from the large chunk of us who don't do open source stuff and manage products with it. Github brings us no benefit then.
- quicksilver03 15y ago
  Irrespective of git vs. hg, there is one case where BitBucket is definitely better than GitHub: when you have many repositories and a variable number of contributors. My company is in this exact situation and we've chosen BitBucket because the pricing model per contributor is a much better fit than GitHub's model for our usage pattern.
  - iwejfweoifjweif 15y ago
    I haven't looked at the pricing for BitBucket but it seems (in my experience) you can have as many contributors as you want in an "organization" on GitHub and you only pay based on the number of private repos that organization has and forks of those repos don't count. Is that not your experience?
    - quicksilver03 15y ago
      BitBucket pricing: https://bitbucket.org/plans https://bitbucket.org/plans GitHub pricing: https://github.com/plans https://github.com/plans We currently have 9 people accessing our 12 source repositories (9 BitBucket users or 9 GitHub collaborators). With BitBucket we pay 10USD/month, with GitHub we would have to pay either 22USD/month (the Medium plan) or 25USD/month (the Bronze plan). In the end, BitBucket's pricing structure is much simpler for us and fits our model much better.
acdha 15y ago
The part which struck me: "For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Keeping this functionality out of core prevents new users from accidentally using it until they’re ready." What this means in practice: when you need to rebase in Git, you simply do so. When you need to rebase in Mercurial, you have to enable a bunch of extensions which aren't well polished or documented because they're not part of the standard feature set and many people have been discouraged from using them. That second situation is far more likely to cause data loss, which is a pity because rewriting local history is a valid operation which often produces cleaner commits and avoids merge failures. I started using Mercurial earlier than Git but have been using both for years. Mercurial remains the only one where I have experienced data-loss (histedit) and the one where I had to switch to a less natural workflow to deal with limitations of the tool (e.g. patch queues are such a kludge-fest it's obvious that nobody really believes you should use this feature).
- kisielk 15y ago
  To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my experience are just as well documented and tested as other bits of Mercurial. It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default. Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.
  - guard-of-terra 15y ago
    Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one. Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase. If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time. Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(
jcoder 15y ago
"Backwards Compatibility The maintainer (and original author) of Mercurial, Matt Mackall, is a strong proponent of backwards compatibility, which is important when you’re choosing a version control system that you plan to rely on for a long time." Well, that's air-tight. You sold me.
- outworlder 15y ago
  And since when GIT ever broke backwards compatibility? almost never. Details below: http://stackoverflow.com/questions/1314668/git-repository-backwards-compatibility http://stackoverflow.com/questions/1314668/git-repository-ba...
  - aninteger 15y ago
    I'm pretty sure jcoder was being sarcastic :).
    - jcoder 15y ago
      Yeah, just drawing attention to the "rigorous discussion" (hand waving).
- tsewlliw 15y ago
  Fwiw, fossil is engineered from the ground up to have an enduring disk representation if that's the top of your list.
falcolas 15y ago
I find the "Easy to Extend" argument very unconvincing. The example shell script is not at all integrated with hg (no more so than any other Unix command), and these are not Windows portable, as the article indicates is so very important. Git appears to have an edge here, since you can integrate shell scripts directly into the git interface. Git allows aliasing just as easily as hg.
luser001 15y ago
I did 'git log' on a repo with 60K commits and about 3k files. I finished in a second or so. I imported that git repo into Mercurial and did 'hg log'. It took 13 sec. This was about 3 years ago. I haven't looked at Mercurial again. Maybe things have changed now?
sdfjkl 15y ago
I used to worry about Git vs. Mercurial too. Neither made me really happy. Then I found Fossil[1]. Now I am coding instead of worrying about version control. [1] http://fossil-scm.org http://fossil-scm.org
- wladimir 15y ago
  I eventually settled on git, for no particular reason but to choose one. They are equivalent for all practical purposes, but require learning different commands to do the same thing. It was taking too much mental bandwidth for me to context-switch between them. It's great to see some diversity though. Edit: There are also plenty of scripts to convert between repositories of one format to another, and communicate between them, another reason to use the one you're comfortable with...
tednaleid 15y ago
Almost all git vs mercurial differences for most users are cosmetic/usability/culture related. With a few extensions turned on, you can use either interchangably. The biggest exception to this is if you use named branches (a fairly common thing in git, slightly less so in mercurial). Mercurial hard codes a branch name in the metadata of a commit, git doesn't do that. I prefer git's method as it means that a commit can move around on branches (or really that branches can point to different commits) without messing with the commits themselves.
- elehack 15y ago
  Branching is one of the big differences. I find Mercurial's named branches mostly useless; fortunately, with some care, bookmarks can be used to simulate Git-style branches. I think, early on, the Mercurial community favored cloning as the means of creating feature branches, while Git used named branches to do so. But in many cases you want to be able to switch lines of development in a single repository (especially when using a workspace-based IDE like Eclipse), so the Git model becomes a win.
codesuela 15y ago
>Many programmers prefer to use a graphical interface to their version control system instead of working through a command line. to be honest git is my first true VCS (because I was used to working on my own and my VCS was Wuala sync that synced every changed document to the cloud + daily backups to another HDD). I have used the built in revision control system in Visual Studio but not extensively. When I started out with git I was looking for a GUI client because I assumed that it would be easier to use but now I much prefer the cli version of git and I assume this is true for most Linux (and possibly Mac users idk). I would even go as far as to assume that this is true for most HN readers. Anyone care to comment? Also git (even direct publishing to github) is built into PyCharm/RubyMine and there is also TortoiseGit for Windows (not sure about other OSs) edit: I just realized this might be slightly OT but I still hope this wont be downvoted into oblivion as I'd love to hear some opinions
- wonderzombie 15y ago
  For my part, I started using git at the command line because most of the Linux GUIs were pretty weak. They may have gotten better since I looked (1 yr?) but at this point I'm comfortable with the command line interface. Also, I jump between Linux at work and OS X at home, and the git workflow is the same on either if I am using the command line. The Mac GitHub app seems really nice, though.
cageface 15y ago
Or, let's be honest, because Github already nailed Git so we had to base bitbucket on something else.
jcapote 15y ago
The need to be a technology contrarian, that's why.
postfuturist 15y ago
Why would their product marketing manager be bashing Git with accusations like Windows support is a "completely separate project" when it's the first download link on git-scm.com? This is a very thoughtless article full of issues of personal taste and FUD towards Git. I was starting to really like Atlassian since they added free private Git repos on bitbucket.org. We've been considering using JIRA and other paid services from them where I work, but this gives me serious pause.
- frio 15y ago
  Not that I'm biased here (I use git and am more than happy on it), but git on Windows is an abomination as compared to Mercurial. Other than the sometimes complex commandline statements, it's one of git's bigger problems.
  - mappu 15y ago
    I tried to git diff the other day. msysgit screams that //its own bundled terminal// "is not fully functional" and dies. Yes, there's a workaround[1], but i'm sticking to Hg at work and at home for now. ____________ 1. http://stackoverflow.com/questions/7949956/git-diff-not-working-terminal-not-fully-functional http://stackoverflow.com/questions/7949956/git-diff-not-work...
  - jandy 15y ago
    An "abomination", really? I use Git regularly--and happily--on Windows with very few issues. It is considerably slower than its Mac/Linux builds, but aside from that the experience has been positive. What exactly do you consider to be Git's failings on Windows? And how is Mercurial superior in those respects?
    - statictype 15y ago
      I haven't used git on Windows for some time now so maybe things have changed, but at that time, it was pretty obvious that Mercurial was a polished first-class citizen of the Windows platform while git was an incomplete port (and in git's defense, I don't believe "make it work on Windows" was ever a design consideration when it was written). I presume things have changed since then but it wasn't always the case.
LeafStorm 15y ago
The fact that the average HN'er seems to be completely unwilling to even consider using a tool different than git is rather depressing. While I understand that git does have some impressive features that Mercurial does not, most of them are somewhat esoteric, and I certainly doubt that they are enough of a motivation to justify this viewpoint that git has already won and that Mercurial is a pile of trash. "The more I use git, the more I realize that everyone enamored with it has a severe case of Stockholm syndrome." -- Matt Might [1] [1] https://twitter.com/#!/mattmight/status/161495662033248256 https://twitter.com/#!/mattmight/status/161495662033248256
wowzer 15y ago
Having used both git and hg in my own projects, I have strong feelings towards both, although in the end they're like siblings who got the same lessons from their parents and just choose to go to different colleges. With that said, I'm not sure this post really pushes one to use hg. The comments about being close to svn are pretty lame. While I get the point; subtle differences really won't matter after the first week. And getting over the mental difference that comes with distributed version control is a lot more to take in than a couple letter changes in commands. The two things I most like about git are how -- by default -- you can choose line-by-line what gets commited. Where as the default in hg is to commit all changes. This actually changes how I find myself coding and my comfort with the repo. I know you can do something similar in hg, but it's a bit of a nuisance. The other standout is how simple branching is in git.

95 points by LeafStorm 15y ago

Regarding the "A Sane Command Line Interface" topic. Linus mentioned in his talk at Google about Git that he often chose the opposite approach to do things rather than follow the Subversion approach. This might be why the commands are not named the same as Subversion commands. git add/rm handles making changes to the index and there is no similar concept in mercurial or subversion.

Argorak 15y ago
I think this is not only about similarity. For example, branching works with `git branch foo`, but it doesn't immediately switch to that branch. If you want to do this, `git checkout -b foo` is the way to go. While this might make some sense if you understand the details behind git, it is horrible from a user interface perspective. I know a lot of people that didn't know about checkout -b because they never thought about looking there. Also, some features are half-implemented, for example `git add -p` which does not trigger on file-additions (and sometimes is broke out of the box on some distros). I like git, but the interface: not so much. Too many rough edges. The blog post does not illustrate this, though :/. Update: and for the downvotes, would you care to explain why?
- weaksauce 15y ago
  I'm not downvoting you but the git branch command is orthogonal to checking out a branch. The branch command adds, removes and lists branches. The checkout command switches between them. There is a convenience command that does a checkout and create. The main thrust of the checkout command is to change branches so if a branch does not exist they give you a convenience method to do so. edit: git add -p(atch) is supposed to create patches of existing files assuming that that is the most common use case. Use --interactive if you want to add new files and still do interactive patching.
  - Argorak 15y ago
    I am aware why the distinction exists - from the perspective of "git(1) manipulates the git file system", it make sense (as I wrote). But most people I know tend to use "branch" for all their branching work (as the name implies) and never bother about the finer details. But the fact that this sore point exists and is real makes the git UI problematic. I don't bother, because I know the details, but if I have to explain it to every new guy in the office, there is something wrong. About git add -p: yes, I am aware of -i, but it doesn't give you the easy "give me all changes to the file system and let me sign them off"-interaction that git add -p has. They are two completely different interaction modes.
    - weaksauce 15y ago
      git add -i 5<enter> *<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc... then <enter> gets you to the staging that you are used to. this will get you into the quick patch mode that -p does. -p is just a short circuit of this.
- jacknagel 15y ago
  You might find `git add -N` ("--intent-to-add") useful. It's an extra step, yes, but it allows you to e.g. view the content of new files with `git diff` without actually staging the content for commit, and will allow you to stage that file during `git add -p`.

benatkin 15y ago

I like what's on the git part of the table better, and it isn't just familiarity with git but familiarity with unix. I'm glad that since I use git and git-svn, I don't have to type remove and move instead of rm and mv.

LeafStorm 15y ago
One thing the article misses is that hg also has a bunch of built-in aliases for a lot of these commands, including: * mv for move * rm for remove * co for clone (which SVN uses as an abbreviation for svn checkout) * ci for commit As well as the fact that you can abbreviate any command that hg doesn't have specific aliases defined for by typing any unambiguous prefix. Git, on the other hand, has no aliases by default, and no prefix aliases.
- julian37 15y ago
  Come on, those are very minor quibbles. If you want aliases, it's literally a matter of five minutes to find some (e.g. [1] is the 4th hit for a google search for "git aliases") and put them into your .gitconfig. And I would argue that prefixes are more confusing than helpful, especially in conjunction with aliases. For instance, going by prefixes you'd expect "co" to mean commit, yet in hg/svn it means clone/checkout. [1] http://gitready.com/intermediate/2009/02/06/helpful-command-aliases.html http://gitready.com/intermediate/2009/02/06/helpful-command-...
- buff-a 15y ago
  Gosh, I know. That's awful. Its much better that hg allows people to type hg mv, rather than forcing lazy people to modify the .bashrc file so that they can type "ga" instead of "git add". I mean, I know "hg mv" is actually longer than "ga", but by golly, expecting unix shell users to know about the alias system built into the operating system is just the kind of elitism we can expect from linus.
  - benatkin 15y ago
    I hate to burst your bubble, but git has alias support. http://githowto.com/aliases http://githowto.com/aliases

badboy 15y ago

It is a bad thing to have just one command to move files instead of 3? Nah, I don't get it. That git has different commands than svn is because it is different. Why should it adopt any of the commands if it does different things? When I started with git, I never ever destroyed any of the history. Because it's not easy to do so. I looking forward to read the follow-up article where he wants to point out some advantages of git.

NelsonMinar 15y ago

GitHub is the first and last reason to prefer Git to anything else. That community is so vital right now, it cements Git as the essential VCS. I could believe Mercurial is better in some ways than Git and I could even believe Atlassian's BitBucket service is in some theoretical sense better than GitHub. But most code is on GitHub, so git wins.

rsanheim 15y ago
This. Github is the killer app for dvcs. Both git and mercurial are good enough, and github simply makes it a no brainer.
- bwarp 15y ago
  Apart from the large chunk of us who don't do open source stuff and manage products with it. Github brings us no benefit then.
quicksilver03 15y ago
Irrespective of git vs. hg, there is one case where BitBucket is definitely better than GitHub: when you have many repositories and a variable number of contributors. My company is in this exact situation and we've chosen BitBucket because the pricing model per contributor is a much better fit than GitHub's model for our usage pattern.
- iwejfweoifjweif 15y ago
  I haven't looked at the pricing for BitBucket but it seems (in my experience) you can have as many contributors as you want in an "organization" on GitHub and you only pay based on the number of private repos that organization has and forks of those repos don't count. Is that not your experience?
  - quicksilver03 15y ago
    BitBucket pricing: https://bitbucket.org/plans https://bitbucket.org/plans GitHub pricing: https://github.com/plans https://github.com/plans We currently have 9 people accessing our 12 source repositories (9 BitBucket users or 9 GitHub collaborators). With BitBucket we pay 10USD/month, with GitHub we would have to pay either 22USD/month (the Medium plan) or 25USD/month (the Bronze plan). In the end, BitBucket's pricing structure is much simpler for us and fits our model much better.

acdha 15y ago

The part which struck me: "For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Keeping this functionality out of core prevents new users from accidentally using it until they’re ready." What this means in practice: when you need to rebase in Git, you simply do so. When you need to rebase in Mercurial, you have to enable a bunch of extensions which aren't well polished or documented because they're not part of the standard feature set and many people have been discouraged from using them. That second situation is far more likely to cause data loss, which is a pity because rewriting local history is a valid operation which often produces cleaner commits and avoids merge failures. I started using Mercurial earlier than Git but have been using both for years. Mercurial remains the only one where I have experienced data-loss (histedit) and the one where I had to switch to a less natural workflow to deal with limitations of the tool (e.g. patch queues are such a kludge-fest it's obvious that nobody really believes you should use this feature).

kisielk 15y ago
To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my experience are just as well documented and tested as other bits of Mercurial. It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default. Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.
- guard-of-terra 15y ago
  Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one. Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase. If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time. Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(

jcoder 15y ago

"Backwards Compatibility The maintainer (and original author) of Mercurial, Matt Mackall, is a strong proponent of backwards compatibility, which is important when you’re choosing a version control system that you plan to rely on for a long time." Well, that's air-tight. You sold me.

outworlder 15y ago
And since when GIT ever broke backwards compatibility? almost never. Details below: http://stackoverflow.com/questions/1314668/git-repository-backwards-compatibility http://stackoverflow.com/questions/1314668/git-repository-ba...
- aninteger 15y ago
  I'm pretty sure jcoder was being sarcastic :).
  - jcoder 15y ago
    Yeah, just drawing attention to the "rigorous discussion" (hand waving).
tsewlliw 15y ago
Fwiw, fossil is engineered from the ground up to have an enduring disk representation if that's the top of your list.

falcolas 15y ago

I find the "Easy to Extend" argument very unconvincing. The example shell script is not at all integrated with hg (no more so than any other Unix command), and these are not Windows portable, as the article indicates is so very important. Git appears to have an edge here, since you can integrate shell scripts directly into the git interface. Git allows aliasing just as easily as hg.

luser001 15y ago

I did 'git log' on a repo with 60K commits and about 3k files. I finished in a second or so. I imported that git repo into Mercurial and did 'hg log'. It took 13 sec. This was about 3 years ago. I haven't looked at Mercurial again. Maybe things have changed now?

sdfjkl 15y ago

I used to worry about Git vs. Mercurial too. Neither made me really happy. Then I found Fossil[1]. Now I am coding instead of worrying about version control. [1] http://fossil-scm.org http://fossil-scm.org

wladimir 15y ago
I eventually settled on git, for no particular reason but to choose one. They are equivalent for all practical purposes, but require learning different commands to do the same thing. It was taking too much mental bandwidth for me to context-switch between them. It's great to see some diversity though. Edit: There are also plenty of scripts to convert between repositories of one format to another, and communicate between them, another reason to use the one you're comfortable with...

tednaleid 15y ago

Almost all git vs mercurial differences for most users are cosmetic/usability/culture related. With a few extensions turned on, you can use either interchangably. The biggest exception to this is if you use named branches (a fairly common thing in git, slightly less so in mercurial). Mercurial hard codes a branch name in the metadata of a commit, git doesn't do that. I prefer git's method as it means that a commit can move around on branches (or really that branches can point to different commits) without messing with the commits themselves.

elehack 15y ago
Branching is one of the big differences. I find Mercurial's named branches mostly useless; fortunately, with some care, bookmarks can be used to simulate Git-style branches. I think, early on, the Mercurial community favored cloning as the means of creating feature branches, while Git used named branches to do so. But in many cases you want to be able to switch lines of development in a single repository (especially when using a workspace-based IDE like Eclipse), so the Git model becomes a win.

codesuela 15y ago

>Many programmers prefer to use a graphical interface to their version control system instead of working through a command line. to be honest git is my first true VCS (because I was used to working on my own and my VCS was Wuala sync that synced every changed document to the cloud + daily backups to another HDD). I have used the built in revision control system in Visual Studio but not extensively. When I started out with git I was looking for a GUI client because I assumed that it would be easier to use but now I much prefer the cli version of git and I assume this is true for most Linux (and possibly Mac users idk). I would even go as far as to assume that this is true for most HN readers. Anyone care to comment? Also git (even direct publishing to github) is built into PyCharm/RubyMine and there is also TortoiseGit for Windows (not sure about other OSs) edit: I just realized this might be slightly OT but I still hope this wont be downvoted into oblivion as I'd love to hear some opinions

wonderzombie 15y ago
For my part, I started using git at the command line because most of the Linux GUIs were pretty weak. They may have gotten better since I looked (1 yr?) but at this point I'm comfortable with the command line interface. Also, I jump between Linux at work and OS X at home, and the git workflow is the same on either if I am using the command line. The Mac GitHub app seems really nice, though.

cageface 15y ago

Or, let's be honest, because Github already nailed Git so we had to base bitbucket on something else.

jcapote 15y ago

The need to be a technology contrarian, that's why.

postfuturist 15y ago

Why would their product marketing manager be bashing Git with accusations like Windows support is a "completely separate project" when it's the first download link on git-scm.com? This is a very thoughtless article full of issues of personal taste and FUD towards Git. I was starting to really like Atlassian since they added free private Git repos on bitbucket.org. We've been considering using JIRA and other paid services from them where I work, but this gives me serious pause.

frio 15y ago
Not that I'm biased here (I use git and am more than happy on it), but git on Windows is an abomination as compared to Mercurial. Other than the sometimes complex commandline statements, it's one of git's bigger problems.
- mappu 15y ago
  I tried to git diff the other day. msysgit screams that //its own bundled terminal// "is not fully functional" and dies. Yes, there's a workaround[1], but i'm sticking to Hg at work and at home for now. ____________ 1. http://stackoverflow.com/questions/7949956/git-diff-not-working-terminal-not-fully-functional http://stackoverflow.com/questions/7949956/git-diff-not-work...
- jandy 15y ago
  An "abomination", really? I use Git regularly--and happily--on Windows with very few issues. It is considerably slower than its Mac/Linux builds, but aside from that the experience has been positive. What exactly do you consider to be Git's failings on Windows? And how is Mercurial superior in those respects?
  - statictype 15y ago
    I haven't used git on Windows for some time now so maybe things have changed, but at that time, it was pretty obvious that Mercurial was a polished first-class citizen of the Windows platform while git was an incomplete port (and in git's defense, I don't believe "make it work on Windows" was ever a design consideration when it was written). I presume things have changed since then but it wasn't always the case.

LeafStorm 15y ago

The fact that the average HN'er seems to be completely unwilling to even consider using a tool different than git is rather depressing. While I understand that git does have some impressive features that Mercurial does not, most of them are somewhat esoteric, and I certainly doubt that they are enough of a motivation to justify this viewpoint that git has already won and that Mercurial is a pile of trash. "The more I use git, the more I realize that everyone enamored with it has a severe case of Stockholm syndrome." -- Matt Might [1] [1] https://twitter.com/#!/mattmight/status/161495662033248256 https://twitter.com/#!/mattmight/status/161495662033248256

wowzer 15y ago

Having used both git and hg in my own projects, I have strong feelings towards both, although in the end they're like siblings who got the same lessons from their parents and just choose to go to different colleges. With that said, I'm not sure this post really pushes one to use hg. The comments about being close to svn are pretty lame. While I get the point; subtle differences really won't matter after the first week. And getting over the mental difference that comes with distributed version control is a lot more to take in than a couple letter changes in commands. The two things I most like about git are how -- by default -- you can choose line-by-line what gets commited. Where as the default in hg is to commit all changes. This actually changes how I find myself coding and my comfort with the repo. I know you can do something similar in hg, but it's a bit of a nuisance. The other standout is how simple branching is in git.