10 ms·

Prefer mercurial to git

142 points by arunc 13y ago

doughj3 13y ago
> I don't get this argument. Windows and Mac OS X are also more popular; does this mean we shouldn't use any other OS because all of the cool games are almost exclusively developed on Windows? Seems like that isn't the same situation. Rather the author should have asked " Windows and Mac OS X are also more popular; does this mean we shouldn't restrict developers to using a non-Windows, non-OS X system?" and the answer is quite simply "no, you shouldn't". Choosing a VCS means every needs to use that VCS. The same is not [necessarily] true for which operating systems can be used for development.
cbhl 13y ago
A lot of these arguments seem to stem about whether git or hg is better, which seems about as useful as arguing vim/emacs or Windows/Linux/OS X -- it depends on what you need and what you already know. If you're okay with using closed-source services, Fog Creek's Kiln allows you to have repositories that can be accessed with both git and hg; commits/branches/bookmarks in one will show up in the other automatically. It seems to me that this argument could be solved if someone went and built a F/OSS equivalent that did the same thing for the emacs devs.
fiorix 13y ago
Seems like discussing religion or politics to me.
jefftchan 13y ago
Relevant: Facebook migrated from git to hg awhile back. Here's a blog post on how they are scaling hg for their monolithic repos https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
- voidr 13y ago
  And by scale they really mean swapped out whole parts of hg, which they could have done with git as well.
octo_t 13y ago
One of his last points seems to be incorrect (or I'm misreading him). One that I like that replaces my most frequent usage of magit is crecord: interactively select hunks for committing. this is literally 'git add -p', and the -p flag can be passed to a load of different git tools to have this functionality?
- stevelosh 13y ago
  You're misreading him. 'hg record' is like 'git add -p', but 'hg crecord' (note the c) is a curses interface: https://bitbucket.org/edgimar/crecord/wiki/Home https://bitbucket.org/edgimar/crecord/wiki/Home
nailer 13y ago
Context? This just seems to be a post from a Mercurial/Hg advocate. Mercurial could be 10% better than git, but unless it's 500% better, it will never displace it.
- hyperbling 13y ago
  emacs is moving off of bzr.
  - deleted 13y ago
    [deleted]
    - Walkman 13y ago
      What are these then? https://github.com/git/git/blob/master/COPYING https://github.com/git/git/blob/master/COPYING https://github.com/git/git/blob/master/LGPL-2.1 https://github.com/git/git/blob/master/LGPL-2.1
      - leobelle 13y ago
        Yeah I was wrong. Thanks!
    - nsmartt 13y ago
      > Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). https://github.com/git/git https://github.com/git/git
    - reaperhulk 13y ago
      Git is (mostly) GPLv2. The other licenses, at least according to git's docs, are GPLv2 compatible.
    - cheradenine01 13y ago
      Huh? Git is GPLv2.
    - deleted 13y ago
spellboots 13y ago
I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git. In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will (did?) happily let you work away at a corrupted repo for weeks until a fresh clone was attempted and the dreaded repo corrupted message killed development for days until the problem was painstakingly manually fixed. This is just personal experience and a lot of it comes down to taste, but IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to. Disclaimer: This was a few years ago now, perhaps the project is more mature than it was.
- indygreg2 13y ago
  I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1]. Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months. I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible. Some things possible in Mercurial that aren't with Git: * Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands. * Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla. * Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself. * Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation. As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way. [1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/ http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-query-mozilla-metadata/ http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...
copx 13y ago
You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00238.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
- belorn 13y ago
  I find git's GPLv2-only license to be a disadvantage when contrasted with hg's GPLv2-or-later. For example, this makes it more awkward to combine git with AGPL code, which is something that we reasonably might want to do for web front-ends. GPLv3 and AGPL have mutual cross-compatibility clauses with each other, but AIUI, GPLv2-only and AGPL don't. Incompatible in this context mean that "GPLv2 only" is causing more license incompatibilities than gplv2+.
- rout39574 13y ago
  Not even RMS holds that position. You should read the thread.
- Codhisattva 13y ago
  Your Tl;dr: is wrong.
  - ehartsuyker 13y ago
    For those of us less aware, could your or copx link to an explanation or why the tl;dr is or isn't wrong, or give us a quick one?
    - uid 13y ago
      Petty factionalism within Open Source where if you don't support the latest views of the GNU committee and Dear Leader then you are against open source (which is ridiculous). Largest dispute has been a lot of GPL projects that won't move to v3 since there are a lot of problems with it. Not even worth replying to, in my opinion.
leobelle 13y ago
My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's no reason to switch. What does hg have that makes it better than git that you should give up git? Popularity is what git has over hg. Someone using git will probably never have to spend anytime worrying about learning hg, but an hg user will have to become familiar with git because git is used everywhere nowadays. So my recommendation to people new to versioning systems is to pick git. I can't for the life of me understand why someone would pick hg for an open source project unless they wanted to throw learning curves and barriers at developers, or they just really really liked hg (probably because they chose it over git a long time ago). [1] http://mercurial.selenic.com/wiki/RevisionNumber http://mercurial.selenic.com/wiki/RevisionNumber [2] http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran...
- twic 13y ago
  > you can't easily have local branches [2] > > http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran... I don't get it. As a citation for your assertion that you can't easily have local branches, you link to a StackOverflow question for which the accepted answer explains how to easily have local branches. What were you trying to say with that link?
  - leobelle 13y ago
    I'm not going to answer your question because I feel like what I said (not tried to say, but said) was obvious, but I will point out that things like this kinda throw a wrench into the whole "hg's UI is better than git" don't ya think?
- pjmlp 13y ago
  > What does hg have that makes it better than git that you should give up git? Better user experience out of the box for Windows shops. This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.
ufmace 13y ago
I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like that. The code that you branched off stays out of your mainline for now, but is easy to switch back to and work on some more. At any time, you can easily delete the branch, and it all effectively disappears, push it somewhere else for somebody else to work on, or merge it back into main when it's ready. Well, merging might be tricky if you wait too long, but you get the idea. Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. What Mercurial really wants you to do is clone your repo, and do that work that would be a Git branch in the clone. But to do that, you have to start with a clean repo, actively decide you want to create a new branch/clone, clone your repo, and only then start doing that work in the clone. If you've already done some work, and then decided that a piece of it ought to be branched off, then your workflow is pretty messy - you have to clone with the work uncommitted, then manually move the changes over to the clone and commit them there. And switch any working directories you might have open to the clone directory to work in it. Yeah, no thanks, I'll stick with Git.
- hyperbling 13y ago
  or just use bookmarks and enjoy the exact same workflow as git.
- zb 13y ago
  That's only true for named branches. You can create an unnamed branch in hg simply by going to a point in the history (what Git would call detached head) and committing. That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.
- masklinn 13y ago
  > Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. `bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named. [0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.
zobzu 13y ago
I use Git and Mercurial daily. They're both ok. However.. I prefer Git to mercurial, mainly because: - Git is noticeably faster for all operations (yeah, specially if you don't use GitHub for pull/push as they're slow as hell ;-) - Git has sensible default settings, for example, git log is easier than hg log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip. (Both are easier to remember, type, and keep the logic across the tool). - Finally, Git handles everything in a generic fashion. Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues, and weird commands such as qpop, qremove, qseries, qnew <= this is very confusing to newcomers. Basically, I feel like Git knows how to KISS better than Mercurial.
- twic 13y ago
  FWIW, my equivalent of 'git show' is 'hg diff -c'. It shows the patch but not the metadata; this is usually what i want. I know what you mean about hg not invoking a pager by default. I understand why the hg maintainers haven't done it, but it's still mildly annoying every time i have to throw in a |less. I have no idea what you're talking about with queues. The last time i used queues was to do stashing back before hg got a proper shelve in the core. I don't think there's any sane use case which requires them now.
- masklinn 13y ago
  > Git has sensible default settings, for example, git log is easier than hg log|less. cat >> ~/.hgrc [pager] pager = less -FRX [extensions] pager= There, I fixed it. > Similarly, git show HEAD^ is easier than hg log --patch --rev tip Wait, what? Those commands do completely different things. What are you trying to do? Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd on its face, why is it easier to have two different commands to see the same thing, with the only difference being the length of the revision set? (yes I know `git show` can also show other objects, but that's now how you used it here). > Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition against what git calls "detached heads", they're just anonymous branches). You have to use MQ if you want to do quilt-type things. Used to be you also had to use it if you wanted to perform extensive history-rewriting, but that hasn't been the case for a few years now.
moron4hire 13y ago
A lot of this just seems like the GNU and FSF being anti-Torvalds, an extension of their clash over the naming of [Linux|GNU/Linux] issue.
- lukeschlather 13y ago
  This is about Torvalds being anti-GPLv3.
  - moron4hire 13y ago
    potato, potahto
lukasm 13y ago
For 99% devs out there these tools boils down to pretty much the same. UPS of git is Github and Linus
jordigh 13y ago
This is a great blog post about Mercurial and git: http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/ http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... tl;dr: "If you take anything away from this post it should be that Mercurial is a flexible and agile tool."
sixthloginorso 13y ago
Why are people sweating small stuff like version control systems? How can you be a fanboy of a thing that keeps track of branches and patches. It's only incidentally related to Software development, you shouldn't feel as if a limb of yours was amputated if you \gasp\ had to use a different one for another project. It's like using a different mail client or a different bug tracker; it doesn't affect what you can express or how can you build a program. It's just Version Control.
- harel 13y ago
  That's true, in a way, until someone tries to force CVS on you. Yes they are all sideline tools but once you get used to something, its the best thing in the world, until you get used to something else. Change is great, but not quite appreciated enough.
  - ygra 13y ago
    At work (where my script to convert all of our projects from CVS to Hg is complete for almost ¾ of a year now) I now resort to a hacky PowerShell script that allows me to work locally with Hg and then push selected revisions to CVS. Mostly because I fear that we won't ditch CVS for quite a while and when we do I'm probably the one to blame for lost developer productivity while we're coming to grips with a new tool.
    - harel 13y ago
      So many wrongs in one comment. The fact you believe you'll be blamed for dev productivity loss is just not right. Blame? The fact you have to write scripts converting from one source control to another is not good, the fact you resort to hacky powershelling is scary. I wasn't even thinking the "are they still using cvs in 2014" even but I guess I should have. "blame" should exist in source control systems only.
      - ygra 13y ago
        Actually I was agreeing to your point that at the time when CVS is used version control is no longer "just a tool" but a PITA. I'm the one who suggested conversion to a newer system, so when the other developers need to re-learn and lose a week of productivity that way it is my fault, to some extent. My conversion script is essentially just automating creating cvs2hg config files for a number of CVS modules (and cleaning up before/after conversion) because our CVS repo is a few GiB in size, containing everything that ever existed (and plenty of things beside that) so a 1:1 conversion isn't that ideal, especially because it will lead to frequent (harmless) merges. But to developers with a CVS background merges are scary. My cvshg PowerShell script is based around https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS and http://pavelchikulaev.wordpress.com/2012/04/09/using-mercurial-locally-along-with-outdated-companys-cvs/ http://pavelchikulaev.wordpress.com/2012/04/09/using-mercuri..., but tailored to how I use the tools. It allows me to commit happily locally and histedit later when I need commits I can actually share with others.
perfunctory 13y ago
Mine might be a very unpopular opinion, but I couldn't care less about different kinds of (D)VCS. I've got a feeling that recently I, and other team members, spend more and more time on branching, rebasing, cloning, merging etc. and less time on actual code writing.
- levesque 13y ago
  Given that you "spend more and more time on branching, rebasing, cloning, merging, etc. and less time on actual code writing", shouldn't you care more about the different kinds of VCS? Seems having the right tool should be important.
blueskin_ 13y ago
Wait, I thought the whole reason they are ditching bzr is that nobody uses it. Why move to mercurial for the same problem?
koobarbara 13y ago
These kinds of posts are on the same level as programming language bashing posts.

142 points by arunc 13y ago

> I don't get this argument. Windows and Mac OS X are also more popular; does this mean we shouldn't use any other OS because all of the cool games are almost exclusively developed on Windows? Seems like that isn't the same situation. Rather the author should have asked " Windows and Mac OS X are also more popular; does this mean we shouldn't restrict developers to using a non-Windows, non-OS X system?" and the answer is quite simply "no, you shouldn't". Choosing a VCS means every needs to use that VCS. The same is not [necessarily] true for which operating systems can be used for development.

cbhl 13y ago

A lot of these arguments seem to stem about whether git or hg is better, which seems about as useful as arguing vim/emacs or Windows/Linux/OS X -- it depends on what you need and what you already know. If you're okay with using closed-source services, Fog Creek's Kiln allows you to have repositories that can be accessed with both git and hg; commits/branches/bookmarks in one will show up in the other automatically. It seems to me that this argument could be solved if someone went and built a F/OSS equivalent that did the same thing for the emacs devs.

fiorix 13y ago

Seems like discussing religion or politics to me.

jefftchan 13y ago

Relevant: Facebook migrated from git to hg awhile back. Here's a blog post on how they are scaling hg for their monolithic repos https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

voidr 13y ago
And by scale they really mean swapped out whole parts of hg, which they could have done with git as well.

octo_t 13y ago

One of his last points seems to be incorrect (or I'm misreading him). One that I like that replaces my most frequent usage of magit is crecord: interactively select hunks for committing. this is literally 'git add -p', and the -p flag can be passed to a load of different git tools to have this functionality?

stevelosh 13y ago
You're misreading him. 'hg record' is like 'git add -p', but 'hg crecord' (note the c) is a curses interface: https://bitbucket.org/edgimar/crecord/wiki/Home https://bitbucket.org/edgimar/crecord/wiki/Home

nailer 13y ago

Context? This just seems to be a post from a Mercurial/Hg advocate. Mercurial could be 10% better than git, but unless it's 500% better, it will never displace it.

hyperbling 13y ago
emacs is moving off of bzr.
- deleted 13y ago
  [deleted]
  - Walkman 13y ago
    What are these then? https://github.com/git/git/blob/master/COPYING https://github.com/git/git/blob/master/COPYING https://github.com/git/git/blob/master/LGPL-2.1 https://github.com/git/git/blob/master/LGPL-2.1
    - leobelle 13y ago
      Yeah I was wrong. Thanks!
  - nsmartt 13y ago
    > Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). https://github.com/git/git https://github.com/git/git
  - reaperhulk 13y ago
    Git is (mostly) GPLv2. The other licenses, at least according to git's docs, are GPLv2 compatible.
  - cheradenine01 13y ago
    Huh? Git is GPLv2.
  - deleted 13y ago

spellboots 13y ago

I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git. In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will (did?) happily let you work away at a corrupted repo for weeks until a fresh clone was attempted and the dreaded repo corrupted message killed development for days until the problem was painstakingly manually fixed. This is just personal experience and a lot of it comes down to taste, but IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to. Disclaimer: This was a few years ago now, perhaps the project is more mature than it was.

indygreg2 13y ago
I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1]. Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months. I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible. Some things possible in Mercurial that aren't with Git: * Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands. * Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla. * Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself. * Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation. As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way. [1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/ http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-query-mozilla-metadata/ http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...

copx 13y ago

You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00238.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.

belorn 13y ago
I find git's GPLv2-only license to be a disadvantage when contrasted with hg's GPLv2-or-later. For example, this makes it more awkward to combine git with AGPL code, which is something that we reasonably might want to do for web front-ends. GPLv3 and AGPL have mutual cross-compatibility clauses with each other, but AIUI, GPLv2-only and AGPL don't. Incompatible in this context mean that "GPLv2 only" is causing more license incompatibilities than gplv2+.
rout39574 13y ago
Not even RMS holds that position. You should read the thread.
Codhisattva 13y ago
Your Tl;dr: is wrong.
- ehartsuyker 13y ago
  For those of us less aware, could your or copx link to an explanation or why the tl;dr is or isn't wrong, or give us a quick one?
  - uid 13y ago
    Petty factionalism within Open Source where if you don't support the latest views of the GNU committee and Dear Leader then you are against open source (which is ridiculous). Largest dispute has been a lot of GPL projects that won't move to v3 since there are a lot of problems with it. Not even worth replying to, in my opinion.

leobelle 13y ago

My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's no reason to switch. What does hg have that makes it better than git that you should give up git? Popularity is what git has over hg. Someone using git will probably never have to spend anytime worrying about learning hg, but an hg user will have to become familiar with git because git is used everywhere nowadays. So my recommendation to people new to versioning systems is to pick git. I can't for the life of me understand why someone would pick hg for an open source project unless they wanted to throw learning curves and barriers at developers, or they just really really liked hg (probably because they chose it over git a long time ago). [1] http://mercurial.selenic.com/wiki/RevisionNumber http://mercurial.selenic.com/wiki/RevisionNumber [2] http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran...

twic 13y ago
> you can't easily have local branches [2] > > http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran... I don't get it. As a citation for your assertion that you can't easily have local branches, you link to a StackOverflow question for which the accepted answer explains how to easily have local branches. What were you trying to say with that link?
- leobelle 13y ago
  I'm not going to answer your question because I feel like what I said (not tried to say, but said) was obvious, but I will point out that things like this kinda throw a wrench into the whole "hg's UI is better than git" don't ya think?
pjmlp 13y ago
> What does hg have that makes it better than git that you should give up git? Better user experience out of the box for Windows shops. This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.

ufmace 13y ago

I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like that. The code that you branched off stays out of your mainline for now, but is easy to switch back to and work on some more. At any time, you can easily delete the branch, and it all effectively disappears, push it somewhere else for somebody else to work on, or merge it back into main when it's ready. Well, merging might be tricky if you wait too long, but you get the idea. Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. What Mercurial really wants you to do is clone your repo, and do that work that would be a Git branch in the clone. But to do that, you have to start with a clean repo, actively decide you want to create a new branch/clone, clone your repo, and only then start doing that work in the clone. If you've already done some work, and then decided that a piece of it ought to be branched off, then your workflow is pretty messy - you have to clone with the work uncommitted, then manually move the changes over to the clone and commit them there. And switch any working directories you might have open to the clone directory to work in it. Yeah, no thanks, I'll stick with Git.

hyperbling 13y ago
or just use bookmarks and enjoy the exact same workflow as git.
zb 13y ago
That's only true for named branches. You can create an unnamed branch in hg simply by going to a point in the history (what Git would call detached head) and committing. That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.
masklinn 13y ago
> Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. `bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named. [0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.

zobzu 13y ago

I use Git and Mercurial daily. They're both ok. However.. I prefer Git to mercurial, mainly because: - Git is noticeably faster for all operations (yeah, specially if you don't use GitHub for pull/push as they're slow as hell ;-) - Git has sensible default settings, for example, git log is easier than hg log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip. (Both are easier to remember, type, and keep the logic across the tool). - Finally, Git handles everything in a generic fashion. Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues, and weird commands such as qpop, qremove, qseries, qnew <= this is very confusing to newcomers. Basically, I feel like Git knows how to KISS better than Mercurial.

twic 13y ago
FWIW, my equivalent of 'git show' is 'hg diff -c'. It shows the patch but not the metadata; this is usually what i want. I know what you mean about hg not invoking a pager by default. I understand why the hg maintainers haven't done it, but it's still mildly annoying every time i have to throw in a |less. I have no idea what you're talking about with queues. The last time i used queues was to do stashing back before hg got a proper shelve in the core. I don't think there's any sane use case which requires them now.
masklinn 13y ago
> Git has sensible default settings, for example, git log is easier than hg log|less. cat >> ~/.hgrc [pager] pager = less -FRX [extensions] pager= There, I fixed it. > Similarly, git show HEAD^ is easier than hg log --patch --rev tip Wait, what? Those commands do completely different things. What are you trying to do? Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd on its face, why is it easier to have two different commands to see the same thing, with the only difference being the length of the revision set? (yes I know `git show` can also show other objects, but that's now how you used it here). > Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition against what git calls "detached heads", they're just anonymous branches). You have to use MQ if you want to do quilt-type things. Used to be you also had to use it if you wanted to perform extensive history-rewriting, but that hasn't been the case for a few years now.

moron4hire 13y ago

A lot of this just seems like the GNU and FSF being anti-Torvalds, an extension of their clash over the naming of [Linux|GNU/Linux] issue.

lukeschlather 13y ago
This is about Torvalds being anti-GPLv3.
- moron4hire 13y ago
  potato, potahto

lukasm 13y ago

For 99% devs out there these tools boils down to pretty much the same. UPS of git is Github and Linus

jordigh 13y ago

This is a great blog post about Mercurial and git: http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git%29/ http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... tl;dr: "If you take anything away from this post it should be that Mercurial is a flexible and agile tool."

sixthloginorso 13y ago

Why are people sweating small stuff like version control systems? How can you be a fanboy of a thing that keeps track of branches and patches. It's only incidentally related to Software development, you shouldn't feel as if a limb of yours was amputated if you \gasp\ had to use a different one for another project. It's like using a different mail client or a different bug tracker; it doesn't affect what you can express or how can you build a program. It's just Version Control.

harel 13y ago
That's true, in a way, until someone tries to force CVS on you. Yes they are all sideline tools but once you get used to something, its the best thing in the world, until you get used to something else. Change is great, but not quite appreciated enough.
- ygra 13y ago
  At work (where my script to convert all of our projects from CVS to Hg is complete for almost ¾ of a year now) I now resort to a hacky PowerShell script that allows me to work locally with Hg and then push selected revisions to CVS. Mostly because I fear that we won't ditch CVS for quite a while and when we do I'm probably the one to blame for lost developer productivity while we're coming to grips with a new tool.
  - harel 13y ago
    So many wrongs in one comment. The fact you believe you'll be blamed for dev productivity loss is just not right. Blame? The fact you have to write scripts converting from one source control to another is not good, the fact you resort to hacky powershelling is scary. I wasn't even thinking the "are they still using cvs in 2014" even but I guess I should have. "blame" should exist in source control systems only.
    - ygra 13y ago
      Actually I was agreeing to your point that at the time when CVS is used version control is no longer "just a tool" but a PITA. I'm the one who suggested conversion to a newer system, so when the other developers need to re-learn and lose a week of productivity that way it is my fault, to some extent. My conversion script is essentially just automating creating cvs2hg config files for a number of CVS modules (and cleaning up before/after conversion) because our CVS repo is a few GiB in size, containing everything that ever existed (and plenty of things beside that) so a 1:1 conversion isn't that ideal, especially because it will lead to frequent (harmless) merges. But to developers with a CVS background merges are scary. My cvshg PowerShell script is based around https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS and http://pavelchikulaev.wordpress.com/2012/04/09/using-mercurial-locally-along-with-outdated-companys-cvs/ http://pavelchikulaev.wordpress.com/2012/04/09/using-mercuri..., but tailored to how I use the tools. It allows me to commit happily locally and histedit later when I need commits I can actually share with others.

perfunctory 13y ago

Mine might be a very unpopular opinion, but I couldn't care less about different kinds of (D)VCS. I've got a feeling that recently I, and other team members, spend more and more time on branching, rebasing, cloning, merging etc. and less time on actual code writing.

levesque 13y ago
Given that you "spend more and more time on branching, rebasing, cloning, merging, etc. and less time on actual code writing", shouldn't you care more about the different kinds of VCS? Seems having the right tool should be important.

blueskin_ 13y ago

Wait, I thought the whole reason they are ditching bzr is that nobody uses it. Why move to mercurial for the same problem?

koobarbara 13y ago

These kinds of posts are on the same level as programming language bashing posts.