25 ms·

Mercurial developer responds to "Switch to git?"

207 points by St-Clock 13y ago

tracker1 13y ago
I really appreciated that this response was not overbearing, or just raw opinion, and rather compared many of the similarities and differences from mercurial to git, and how they approach similar issues differently. Honestly, I've struggled in moving from SVN/TFS to GIT, but it's been worthwhile.. having local branching, and being able to work locally is great. I can't really compare this to hg, as I haven't worked with mercurial at all. The company I work for has moved a lot of its' development to a github enterprise deployment, and it's been interesting. I like git extensions for windows, though it's a bit rough around the edges. It's also a bit limited in terms of VS integration, but I can manage. I think that Tortoise + Ankh was a better combination overall in terms of the polish of the tooling, over what git currently offers. I tend to now work with a few console windows open, and have been using the command line much more.
- voltagex_ 13y ago
  I use TFS at work and Git at home - I do miss Visual Studio's merge features which have been greatly improved in 2012 and 2013. How did you get your head around resolving merge conflicts in Git?
  - weaksauce 13y ago
    it's not too bad in git. you just look at the merge conflict markers in each of the files specified, delete or merge what you want in each of the files, then add the changes to the staging area, and commit again to complete the merge. this might help: http://stackoverflow.com/a/7589612 http://stackoverflow.com/a/7589612 and this: http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...
    - rallison 13y ago
      Even better, one can specify a mergetool in their config, and use a standard diff tool to resolve conflicts.
      - taspeotis 13y ago
        At work, my Git repos are exclusively C# and I've been using SemanticMerge [1] for resolving conflicts to good effect. [1] https://www.semanticmerge.com/ https://www.semanticmerge.com/
        voltagex_ 13y ago
        It's a pity they're a subscription and also they want me to log in to view the pricing. Edit: There is a once-off price and also somewhere to apply if you're working on open source.
  - bitwize 13y ago
    It's as easy as searching for ">>>>" in your text editor; the conflicts will be clearly marked and you take the markers out and make the merged code look the way you want it.
    - skeletonjelly 13y ago
      Or use my favourite conflict program p4merge
- _stephan 13y ago
  You should try SourceTree, it's a great Windows and Mac Git GUI client! It's free (as in beer) and also supports Mercurial.
  - voltagex_ 13y ago
    I second SourceTree - if there's something missing that you need, Atlassian are surprisingly responsive to feature and bug reports.
    - yapcguy 13y ago
      I like SourceTree but it the UI gets clunky and slow within a short period of time. Not sure why, but it usually happens when you have anything more than a trivial number of commits.
      - _stephan 13y ago
        Have you tried it in the last few days? After SourceTree got relatively slow for me with the past few updates, the last update actually completely fixed that!
        emn13 13y ago
        I use SourceTree for git, but I find TortoiseHg is better for mercurial; it's just far more feature complete, with support for almost all mercurial commands and (bundled) extensions. I'm still somewhat surprised by how poor git gui's are, considering it's the more popular VCS - though SourceTree is certainly one of the better ones.
        luastoned 13y ago
        I was really happy when I heard about SourceTree(back then it was not even released yet) but when it finally came out it was bulky to begin with. TortoiseHg on the other hand always looked nice and clean.
  - 13y ago
- matwood 13y ago
  My normal workflow with git is through the cli. Cli really is the best way to use it since git is good at prodding you along to do the right thing. Make sure to go find a good set of aliases and turn on git prompt. When I need to look at histories or large change sets I'll open up SourceTree or go to the BitBucket repos. If I need to see the file history of a single file gitk -p -- file is the quickest way that I have found. I'm currently dealing with 2 projects that are similar and share code but are in different repos. Git has made it easy to add remotes to each project and cherry pick commits that need to be shared. As someone who started with VSS years ago, Git continues to amaze me with how easy it makes source wrangling.
  - hrjet 13y ago
    What is "git prompt" and how do I turn it on? A quick search didn't reveal anything.
    - riannucci 13y ago
      I think the parent is meaning something like the git-status integration of e.g. oh-my-zsh [0], or something like the 'official' git-status integration script for bash [1] (I've used the former, but not the latter.) [0] https://github.com/robbyrussell/oh-my-zsh https://github.com/robbyrussell/oh-my-zsh [1] https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh https://raw.github.com/git/git/master/contrib/completion/git...
    - matwood 13y ago
      Add this to wherever you setup your bash prompt: source /usr/local/git/contrib/completion/git-prompt.sh source /usr/local/git/contrib/completion/git-completion.bash GIT_PS1_SHOWDIRTYSTATE=true export PS1='\u@\h \[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 "\[\033[01;33m\](%s)\[\033[00m\]")$ ' source ~/.profile What this does is add a git style prompt anytime you are in a directory managed by git. On the prompt it will show your current branch, what state it is in (+'s/*'s show if you have changes), if your are merging/rebasing/cherry-picking/etc... The source files may live in slightly different places on your machine depending on where you installed git. This above also adds tab completion for git commands, branches, tags, etc... Also, see my .gitconfig for aliases I have put together from various places on the net: https://github.com/matwood/cfg/blob/master/.gitconfig https://github.com/matwood/cfg/blob/master/.gitconfig
- w0rd-driven 13y ago
  SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother. My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experience that much easier. It makes discovery pretty simple compared to TortoiseGit/SVN where you have to know what each menu item maps to. I've since moved to GIT for work and personal use. GIT flow sold me as hg flow really didn't feel equivalent. I also like submodules as they make proper segregation that much easier. Hg has patch queues which made working on items that weren't commit ready easy. At the time, I didn't understand feature branches so I should likely revisit Hg earnestly. Hg has always had a better user experience where error messages aren't cryptic but there's a wealth of knowledge online to solve any problem in either DVCS at this point. There's some spots in git where you still need the command line where TortoiseHg seemed to cover every need I had. TFS finally supporting git as a repository, despite its caveats (convert once, only vs2012+) will likely push git pretty far. Having used Ankh, I was never impressed. I'd rather use tortoise + git source control plugin or git extensions as the experience is definitely sufficient. I actually prefer the tortoise workflow over doing it all in vs though but there's a bulk of what we do outside of vs anyway so being proficient there helps tremendously.
  - voltagex_ 13y ago
    Have you tested 4.5? What breaks?
    - bgrainger 13y ago
      A significant problem is that once .NET 4.5 is installed, a developer can no longer test how an app behaves under .NET 4, even if the app still has its target framework set to .NET 4. There are several major WPF bugs fixed in .NET 4.5; developers will no longer encounter those bugs locally, but can only find them on a dedicated .NET 4 testing machine, or (more likely) reported from a .NET 4 customer in the field. There's a detailed writeup of the problem here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c02-de67-47a9-b4ed-fd8b622a7e4a/if-i-target-net-40-but-run-on-a-machine-that-has-net-45-will-net-40-wpf-bugs-still-be-there?forum=wpf http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c... See also this suggestion: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3095632-make-vs2012-not-hide-net-4-0-bugs-when-targeting- http://visualstudio.uservoice.com/forums/121579-visual-studi...
St-Clock 13y ago
I quit using Mercurial around 1.4 and was happily surprised by all the improvements in 2.8 (shelve, bookmark improvements, etc.). Martin Geisler's reply was both thoughtful and respectful, a rare sight in this debate.
- weaksauce 13y ago
  > Martin Geisler's reply was both thoughtful and respectful, a rare sight in this debate. I have seen this debate plenty of times but I'd hesitate to say that the overwhelming majority of times are hostile. I think the mercurial guys know that their tool is good with some flaws and that they know that the git tool is good with some flaws and that most other tools are not quite as good. The typical reaction that I have seen is I don't care which one you use if you are using git or hg or some other equally capable revision control scheme. I definitely agree that Mr. Geilser's response was well thought out and polite.
DigitalSea 13y ago
It's refreshing to see someone with a level-headed response who doesn't fly off the rails defending their source control tool of choice, unlike what you usually see with developers of well-known frameworks like PHP and Ruby. I don't personally use Mercurial myself, but it doesn't seem like a bad source control choice, anything is better than SVN, right? Git and Mercurial both seem like great and sensible choices.
- nostrademons 13y ago
  This type of response is quite common in many open-source communities. The trick to finding it is to consider carefully the motivations of why someone wants to participate in open-source. If you have a problem, you wrote a tool to solve it, and you want to share that tool with the rest of the world, you won't be threatened when someone else has a competing tool to share with the rest of the world. Just explain why your tool is useful, and under what circumstances, and let people make up their own minds. It's no skin off your back if they choose not to use it. If you participate in open-source to gain social approval and hacker cred, however, then it's very threatening when other people choose to use a competing tool. If your users disappear, so will your social approval, and you'll be left feeling alone and unwanted. And so people who are in open-source for this motivation frequently put-down technologies that that compete with their own favorite tools. Sometimes it's not even the tools' authors that do this; it is people who have adopted the tool and feel like their choice of preferred tool will be threatened if others adopt different tools. Hence, fanboyism. I have found, when evaluating technologies, that I rarely go wrong trying to select for the first category of community over the second. The problem is that there's a bit of an adverse selection effect. If you ask "What's the best framework for X?", then all the people in the second category will rush to defend their favorite tool, while the people in the first category may present cogent arguments for their tool of choice but won't seem all that impassioned. Human beings are hard-wired to recognize passion, but we typically cannot recognize experience until we have had that experience itself. And so your natural tendency will be to pick frameworks in the second category unless you specifically try to look past the arguments and look at the motivations and background of the people making the arguments.
- TillE 13y ago
fhd2 13y ago
After 4 years of Git and 1 year of Mercurial, I like them roughly equally. I love cheap local branches, I also love MQ. They're just tools, I wish people could get over this kind of stuff. If this is really about getting more contributors, I suggest a GitHub mirror. We do that, it's not a big deal (hg-git is pretty good), and it does get us more contributors.
jheriko 13y ago
i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use, and actually i consider the things that git does differently to hg to be demonstrably and measurably counter-intuitive and in some cases dangerous. the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. why can't i roll back a merge in one step if i didn't configure things to be able to do that? why does my branch disappear when i merge? how do the jenkins guys break their repo so casually and find themselves struggling to recover it? i believe this is the robustness mentioned here: "The changeset graph is in some sense more "robust" in that it's just there and doesn't change on its own initiative" mercurial seems loathe to alter history - which is pretty sane and common sensical seeming to me, git does it as part of how it is 'supposed to be used' which frankly sounds as mad as travelling back in time to shoot your grandfather. for these reasons - to me - using git is asking for trouble (it has caused me trouble and i switched to hg for precisely this reason). i cant reasonably recommend git to anyone... which is a shame. other than that flaw it is really quite rich and powerful and has other advantages over mercurial - including (perhaps foremost) its enormous popularity. EDIT: watch as this gets downvoted from hipster gut responses instead of thought :D
- Pxtl 13y ago
  Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?
  - Mindless2112 13y ago
    > Do we need source-control on our source-control? That's more or less what Mercurial's changeset evolution [1] is/will be (it's not enabled by default yet). [1] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
philliphaydon 13y ago
I don't think Mercurial is the issue here... Google Code is the issue... Didn't realise people still used that, its worse than Codeplex. Atleast use Bitbucket or something that makes it easier for people to contribute to while still keeping it with Mercurial. I've found bugs in stuff before and ended up using a different project/library for the sole reason that I found out its in Google Code and the amount of effort involved in using the site let alone raising an issue or fixing it just wasn't worth it.
- leokun 13y ago
  Agreed, Google Code is awful. The tree ui for browsing code is so very terrible. Browsing commits is a terrible pain. Viewing diffs is awful. And the site just looks ugly and is hard to use. I was tired of Google Code before I even knew about GitHub, I had switched to Unfuddle.
shadowmint 13y ago
I think the big summary of this post comes down to, if you don't have something like: [extensions] shelve = histedit = rebase = mq = As a git developer using hg you're going to be frustrated by all the things 'hg doesn't support'. It doesn't actually not support them, they're just (for some reason?) shipped with hg but not turned on by default.
- asperous 13y ago
  I'm not sure about shelve, but histedit, rebase, and mq are all history modifying extensions. Mercurial differs from git in that it prefers immutable history. The extensions are there if you really need them, not as something you should always setup imo.
  - wangweij 13y ago
    Modifying local history is not dangerous, so I think mq is good. Never really used histedit and rebase.
  - mrtngslr 13y ago
    I don't think this is true today. Git and Mercurial have the same basic model, which means that a commit is immutable because the identity of a commit is determined by its content. This means that you must re-create a changeset in both systems if you want to "change" it. Mercurial and Git can do this and have been doing it for years. The difference is that Git has a built-in concept of garbage collection whereas Mercurial does not. So commands that modify history in Mercurial must trigger the garbage collection (we call it strip) manually -- and they do, of course. So you wont see any big difference between 'hg rebase' and 'git rebase'. They both build new commits and remove the old commits (in Git they're removed eventually, in Mercurial they're removed immediatedly, but with a backup if you want to restore the pre-rebase state). The latest versions of Mercurial has history modification built-in: you can 'hg commit --amend' without enabling any extensions. The changeset evolution concept will take this even further and allow really cool collaborative editing of shared history.
ggchappell 13y ago
Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related to a project. The project is what we are interested in: the Python or C++ or LaTeX or whatever. Git, Mercurial, etc. are just there to help us keep track of the real work. Time spent dealing with the intricacies of Git is time not spent on the primary task -- the thing that Git is supposed to help us with. Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data. I think a well-designed DVCS would be thought of in much the same way. Clearly, current DVCSs aren't. Something is very much amiss, folks.
- venomsnake 13y ago
  All software has its quirks. And it shows when you move out of the ultra comfort zone. If you want to drill a hole in the wall you need to take into consideration the size of the hole, the power of the drill and what are you drilling in. You cannot abstract them. And then one day someone decides to use your python code not on ReiserFS but on Ext2 that has no journaling and all hell could break loose.
- migrantgeek 13y ago
  If you're just storing data, your analogy is fine. It breaks down with more advanced usage like integrations which can be very difficult with large teams. I manage a VCS with thousands of developers committing to a large code base. The VC system starts to really matter and you have to understand how it handles things like conflict resolution or things can get out of hand really quickly.
- gkoberger 13y ago
  Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worrying about Python. Change for the sake of change is bad, but change for the sake of an improved workflow is good.
MikeTLive 13y ago
Ive been using perforce/p4 since 97. the last 8 years have been coupled with P4V and the eclipse plugins. My workflow is virtually identical to the much offered Git branching model [0]. Turn it -90deg with time left to right. Rename "develop" to "trunk". and think of "master" as being the release labels. release and feature branches are created from the build label of the previous release needing special changes that can not just go into trunk or when we want to do a minimal patch-only release. a developer makes local copy of the portions of the trunk they want/need. the server knows who has what opened for edit/add which makes checkins fast. only the change must go in. same for regular update of my local workspace. we rarely have people editing the same exact file and if we do its a simple resolve in P4V during your commit or integrate activity. So far, there are FEW benefits i see to using, or switching to, GIT: LOCAL REPOSITORY - I have the whole repo for what i am working on so can work remote easier LOCAL VERSIONING - I can create lightweight local branches that duplicate only what is required without resync of my local repo POPULARITY - all the cook kids are using it so lots of ops utilities now are built expecting it to be there under the covers. I can live without the LOCAL benefits. I have for 8 years. I worry about the third - popularity vs. merit. Where are the concrete comparisons showing all the features and functions of these solutions side by side and how they compare for a student, startup, or enterprise? EDIT: found a newer perforce:git comparison on the perforce site[1]. The LOCAL REPO/VERSIONING is available with P4SANDBOXING. I suppose modding me down is appropriate since i picked up on the POPULARITY aspect of the discussion and don't have any Hg experience. However, it seems these discussions just keep happening and there is no one-true-solution or approach. they each have merits and faults. it will be the careful consideration of these that leads to your own solution implementation. The popularity of GIT appears to be its strongest argument. EDIT2: located a GIT-v-Perforce on SO.[2] so many of the diffs, however, have been met with sandboxing It really appears the strength is in popularity - everyone else uses GIT so you should too… [0]: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ [1]: http://www.perforce.com/sites/default/files/pdf/perforce-git-comparison.pdf http://www.perforce.com/sites/default/files/pdf/perforce-git... [2]: http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave http://stackoverflow.com/questions/222782/git-vs-perforce-tw...
- rallison 13y ago
eddiegroves 13y ago
Mercurial's changeset evolution sounds really powerful and seems to address the 'git rebase and force push' problems that can occur.
- cpeterso 13y ago
  Here's a video of a FOSDEM 2013 talk about Mercurial's changeset evolution: https://air.mozilla.org/changesets-evolution-with-mercurial/ https://air.mozilla.org/changesets-evolution-with-mercurial/
encoderer 13y ago
Having used both extensively, Git at one job, HG at the next, now Git again, I mostly have this to say: Both tools lack polish. The biggest piece of mis-information I'd like to clear up is that often times a user new to either of these makes a few mistakes and then the cold hand of death grabs them and they're certain they lost work. You never really do. In Mercurial, the permanent nature of named branches and in Git the reflog both serve you well. Seek help in such a case, because if you think you lost work, you almost certainly didn't. Edit: Also, if you're using HG and not using patch queues, you're doing it wrong. Just sayin'
- eru 13y ago
  I've used patch queues with hg, but there are other tools available. For example bookmarks allow you to use hg more like git. Hg with patch queues is a bit like using git and always rebasing, almost never merging. You do lose history with patch queues.
riannucci 13y ago
Author/thread starter here: Really didn't think this post would have generated as much interest as it did when I created it... :D It's a fairly enlightening thread though. Mad props to Martin for a fantastically thoughtful reply!
- CmonDev 13y ago
  So, you are not switching now, hopefully?
oleganza 13y ago
"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are mostly about collaboration, non-stable identifiers can be very confusing.
- gecko 13y ago
  They can't change in a given repo unless you use history-modifying extensions. They do differ between repos. Most modern third-party tools, including Kiln, hide them by default for this reason.
  - oleganza 13y ago
    Thanks for clarifying this. I haven't touched mercurial for a while.
- mrtngslr 13y ago
  Revision numbers are stable within a given repository. The revision number for a commit is simply the index of the commit in the changelog — nothing more. Since a changeset must come after its parent in the changelog, the revision numbers give you a topological ordering of the changesets. A topological ordering is often not unique — this is why revision numbers can differ between repositories, even if they contain exactly the same commits. Because the changelog is append-only, new commits you pull in get higher revision numbers than the existing commits. Your existing revision numbers will thus not change when you do 'hg pull' and 'hg merge'. We don't actually guarantee that revision numbers cannot change when you pull, but it's been the case until now. In any case, the stability of the revision numbers isn't why we like them — we like them since it's often easier to type 'hg histedit 12345' than 'hg histedit c38c3fdc8b93' when you've looked up a particular changeset in your (local!) repository. Hosting sites like Bitbucket and Kiln will wisely not show you revision numbers since the concept is meaningless when talking about more than one repository.
cbhl 13y ago
Part of me wonders whether this is an instance of "The Magpie Developer"[0]. I know that I personally prefer git and bzr over cvs and svn, but just ten years ago, people were all talking about how Linux had just switched to BitKeeper. I also suspect that rather than having a bikeshed-esque argument about switching between one DVCS and another, we can come up with technical solutions to enable everyone to work together. For example, when I was interning at Facebook two years ago, git-svn was used extensively to let the rank-and-file employees work with git, while still allowing chuckr to deploy off of SVN. For mercurial and git, there are services like Kiln Harmony[1] and hg-git, too. [0] http://www.codinghorror.com/blog/2008/01/the-magpie-developer.html http://www.codinghorror.com/blog/2008/01/the-magpie-develope... [1] https://secure.fogcreek.com/kiln/ https://secure.fogcreek.com/kiln/
tytso 13y ago
After reading most of the comments, and having participated on more than a few git vs. <insert random DCVS> discussions, here are what I hope are some hopefully new contributions. All systems have different tradeoffs depending the target audience that they are trying to optimize for. When comparing bzr, hg, and git, one way of thinking about it is that they differ in the size of the developer community of the project that they are trying to optimize for. The sweet spot of bzr is probably up to ten or so active developers at one time; for hg, it's probably up to around hundred or so; and for git, it's designed to scale up to several thousand active developers. Different people might want to argue over the exact breakpoints, but in terms of orders of magnitude, I think it's pretty close. One comment that was made in a thread below was that git was optimized for the people who integrate code, as opposed for those who actually produce the code --- and I think that's mostly true. Which is to say, when there was a choice between optimizing for a project which might make things easier for the integrator, or for the sub-integrator, or sub-sub-integrators (in Linux code integration happens in hierarchically; it's the only way we can scale), and making it easier for a newbie coder, git has very unapologetically optimized for the former. It's true that there are some warts which caused by legacy UI decisions which would probably have made differently if the designers could go back in time, but in my mind these are in the cateogry of things like TAB characters being significant in Makefiles; it's annoying, but practitioners very quickly learn how to deal with these warts, and they generally don't cause significant problems once people get over the startup hump. The other observation is that since choice of which DCVS gets made is generally made by project leads, who tend to be the integrators, it's not that surprising that git is very popular for them. It's also true that most project leads tend to be over-optimistic about whether their project will be the one that will grow up to have thousands of active committers (just as most startup founders are convinced that their baby will be the defeat the odds and become the wildly successful IPO whose market cap will exceed $4 billion dollars :-). Given that most projects generally don't have thousands and thousands of active developers, it might be that hg is a better choice for most projects. However, if most of your senior developers are more used to using git, because that's what they are mostly familiar with, maybe you might want to use git even though the project's scale is one that would be quite satisfied with hg. For me, the e2fsprogs project falls in that category; while the number active developers are such that hg would be fine, most of the developers are simply much more used to git, and so we use git. The third reason why git has probably become popular is because github is really good at hiding many of git's rough edges, and if people are used to github, then it might be a good set of training wheels before people graduate to using git without github's training wheels. If these three factors don't apply to your community, then maybe hg is a better choice for you. If that's true, then don't hesitate! One thing that most people forget is that while transitioning between DCVS is painful, it can be done. So if it turns out the situation changes in three or five years, it is certainly possible to convert your project from hg to git. It will be rough for a month or two, but for some projects, that might actually be better than starting with git, and then finding out that it caused some increased friction initially, and that they never needed the scale that git provides.

207 points by St-Clock 13y ago

I really appreciated that this response was not overbearing, or just raw opinion, and rather compared many of the similarities and differences from mercurial to git, and how they approach similar issues differently. Honestly, I've struggled in moving from SVN/TFS to GIT, but it's been worthwhile.. having local branching, and being able to work locally is great. I can't really compare this to hg, as I haven't worked with mercurial at all. The company I work for has moved a lot of its' development to a github enterprise deployment, and it's been interesting. I like git extensions for windows, though it's a bit rough around the edges. It's also a bit limited in terms of VS integration, but I can manage. I think that Tortoise + Ankh was a better combination overall in terms of the polish of the tooling, over what git currently offers. I tend to now work with a few console windows open, and have been using the command line much more.

voltagex_ 13y ago
I use TFS at work and Git at home - I do miss Visual Studio's merge features which have been greatly improved in 2012 and 2013. How did you get your head around resolving merge conflicts in Git?
- weaksauce 13y ago
  it's not too bad in git. you just look at the merge conflict markers in each of the files specified, delete or merge what you want in each of the files, then add the changes to the staging area, and commit again to complete the merge. this might help: http://stackoverflow.com/a/7589612 http://stackoverflow.com/a/7589612 and this: http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...
  - rallison 13y ago
    Even better, one can specify a mergetool in their config, and use a standard diff tool to resolve conflicts.
    - taspeotis 13y ago
      At work, my Git repos are exclusively C# and I've been using SemanticMerge [1] for resolving conflicts to good effect. [1] https://www.semanticmerge.com/ https://www.semanticmerge.com/
      - voltagex_ 13y ago
        It's a pity they're a subscription and also they want me to log in to view the pricing. Edit: There is a once-off price and also somewhere to apply if you're working on open source.
- bitwize 13y ago
  It's as easy as searching for ">>>>" in your text editor; the conflicts will be clearly marked and you take the markers out and make the merged code look the way you want it.
  - skeletonjelly 13y ago
    Or use my favourite conflict program p4merge
_stephan 13y ago
You should try SourceTree, it's a great Windows and Mac Git GUI client! It's free (as in beer) and also supports Mercurial.
- voltagex_ 13y ago
  I second SourceTree - if there's something missing that you need, Atlassian are surprisingly responsive to feature and bug reports.
  - yapcguy 13y ago
    I like SourceTree but it the UI gets clunky and slow within a short period of time. Not sure why, but it usually happens when you have anything more than a trivial number of commits.
    - _stephan 13y ago
      Have you tried it in the last few days? After SourceTree got relatively slow for me with the past few updates, the last update actually completely fixed that!
      - emn13 13y ago
        I use SourceTree for git, but I find TortoiseHg is better for mercurial; it's just far more feature complete, with support for almost all mercurial commands and (bundled) extensions. I'm still somewhat surprised by how poor git gui's are, considering it's the more popular VCS - though SourceTree is certainly one of the better ones.
        luastoned 13y ago
        I was really happy when I heard about SourceTree(back then it was not even released yet) but when it finally came out it was bulky to begin with. TortoiseHg on the other hand always looked nice and clean.
- 13y ago
matwood 13y ago
My normal workflow with git is through the cli. Cli really is the best way to use it since git is good at prodding you along to do the right thing. Make sure to go find a good set of aliases and turn on git prompt. When I need to look at histories or large change sets I'll open up SourceTree or go to the BitBucket repos. If I need to see the file history of a single file gitk -p -- file is the quickest way that I have found. I'm currently dealing with 2 projects that are similar and share code but are in different repos. Git has made it easy to add remotes to each project and cherry pick commits that need to be shared. As someone who started with VSS years ago, Git continues to amaze me with how easy it makes source wrangling.
- hrjet 13y ago
  What is "git prompt" and how do I turn it on? A quick search didn't reveal anything.
  - riannucci 13y ago
    I think the parent is meaning something like the git-status integration of e.g. oh-my-zsh [0], or something like the 'official' git-status integration script for bash [1] (I've used the former, but not the latter.) [0] https://github.com/robbyrussell/oh-my-zsh https://github.com/robbyrussell/oh-my-zsh [1] https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh https://raw.github.com/git/git/master/contrib/completion/git...
  - matwood 13y ago
    Add this to wherever you setup your bash prompt: source /usr/local/git/contrib/completion/git-prompt.sh source /usr/local/git/contrib/completion/git-completion.bash GIT_PS1_SHOWDIRTYSTATE=true export PS1='\u@\h \[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 "\[\033[01;33m\](%s)\[\033[00m\]")$ ' source ~/.profile What this does is add a git style prompt anytime you are in a directory managed by git. On the prompt it will show your current branch, what state it is in (+'s/*'s show if you have changes), if your are merging/rebasing/cherry-picking/etc... The source files may live in slightly different places on your machine depending on where you installed git. This above also adds tab completion for git commands, branches, tags, etc... Also, see my .gitconfig for aliases I have put together from various places on the net: https://github.com/matwood/cfg/blob/master/.gitconfig https://github.com/matwood/cfg/blob/master/.gitconfig
w0rd-driven 13y ago
SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother. My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experience that much easier. It makes discovery pretty simple compared to TortoiseGit/SVN where you have to know what each menu item maps to. I've since moved to GIT for work and personal use. GIT flow sold me as hg flow really didn't feel equivalent. I also like submodules as they make proper segregation that much easier. Hg has patch queues which made working on items that weren't commit ready easy. At the time, I didn't understand feature branches so I should likely revisit Hg earnestly. Hg has always had a better user experience where error messages aren't cryptic but there's a wealth of knowledge online to solve any problem in either DVCS at this point. There's some spots in git where you still need the command line where TortoiseHg seemed to cover every need I had. TFS finally supporting git as a repository, despite its caveats (convert once, only vs2012+) will likely push git pretty far. Having used Ankh, I was never impressed. I'd rather use tortoise + git source control plugin or git extensions as the experience is definitely sufficient. I actually prefer the tortoise workflow over doing it all in vs though but there's a bulk of what we do outside of vs anyway so being proficient there helps tremendously.
- voltagex_ 13y ago
  Have you tested 4.5? What breaks?
  - bgrainger 13y ago
    A significant problem is that once .NET 4.5 is installed, a developer can no longer test how an app behaves under .NET 4, even if the app still has its target framework set to .NET 4. There are several major WPF bugs fixed in .NET 4.5; developers will no longer encounter those bugs locally, but can only find them on a dedicated .NET 4 testing machine, or (more likely) reported from a .NET 4 customer in the field. There's a detailed writeup of the problem here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c02-de67-47a9-b4ed-fd8b622a7e4a/if-i-target-net-40-but-run-on-a-machine-that-has-net-45-will-net-40-wpf-bugs-still-be-there?forum=wpf http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c... See also this suggestion: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3095632-make-vs2012-not-hide-net-4-0-bugs-when-targeting- http://visualstudio.uservoice.com/forums/121579-visual-studi...

St-Clock 13y ago

I quit using Mercurial around 1.4 and was happily surprised by all the improvements in 2.8 (shelve, bookmark improvements, etc.). Martin Geisler's reply was both thoughtful and respectful, a rare sight in this debate.

weaksauce 13y ago
> Martin Geisler's reply was both thoughtful and respectful, a rare sight in this debate. I have seen this debate plenty of times but I'd hesitate to say that the overwhelming majority of times are hostile. I think the mercurial guys know that their tool is good with some flaws and that they know that the git tool is good with some flaws and that most other tools are not quite as good. The typical reaction that I have seen is I don't care which one you use if you are using git or hg or some other equally capable revision control scheme. I definitely agree that Mr. Geilser's response was well thought out and polite.

DigitalSea 13y ago

It's refreshing to see someone with a level-headed response who doesn't fly off the rails defending their source control tool of choice, unlike what you usually see with developers of well-known frameworks like PHP and Ruby. I don't personally use Mercurial myself, but it doesn't seem like a bad source control choice, anything is better than SVN, right? Git and Mercurial both seem like great and sensible choices.

nostrademons 13y ago
This type of response is quite common in many open-source communities. The trick to finding it is to consider carefully the motivations of why someone wants to participate in open-source. If you have a problem, you wrote a tool to solve it, and you want to share that tool with the rest of the world, you won't be threatened when someone else has a competing tool to share with the rest of the world. Just explain why your tool is useful, and under what circumstances, and let people make up their own minds. It's no skin off your back if they choose not to use it. If you participate in open-source to gain social approval and hacker cred, however, then it's very threatening when other people choose to use a competing tool. If your users disappear, so will your social approval, and you'll be left feeling alone and unwanted. And so people who are in open-source for this motivation frequently put-down technologies that that compete with their own favorite tools. Sometimes it's not even the tools' authors that do this; it is people who have adopted the tool and feel like their choice of preferred tool will be threatened if others adopt different tools. Hence, fanboyism. I have found, when evaluating technologies, that I rarely go wrong trying to select for the first category of community over the second. The problem is that there's a bit of an adverse selection effect. If you ask "What's the best framework for X?", then all the people in the second category will rush to defend their favorite tool, while the people in the first category may present cogent arguments for their tool of choice but won't seem all that impassioned. Human beings are hard-wired to recognize passion, but we typically cannot recognize experience until we have had that experience itself. And so your natural tendency will be to pick frameworks in the second category unless you specifically try to look past the arguments and look at the motivations and background of the people making the arguments.
TillE 13y ago

fhd2 13y ago

After 4 years of Git and 1 year of Mercurial, I like them roughly equally. I love cheap local branches, I also love MQ. They're just tools, I wish people could get over this kind of stuff. If this is really about getting more contributors, I suggest a GitHub mirror. We do that, it's not a big deal (hg-git is pretty good), and it does get us more contributors.

jheriko 13y ago

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use, and actually i consider the things that git does differently to hg to be demonstrably and measurably counter-intuitive and in some cases dangerous. the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state. why can't i roll back a merge in one step if i didn't configure things to be able to do that? why does my branch disappear when i merge? how do the jenkins guys break their repo so casually and find themselves struggling to recover it? i believe this is the robustness mentioned here: "The changeset graph is in some sense more "robust" in that it's just there and doesn't change on its own initiative" mercurial seems loathe to alter history - which is pretty sane and common sensical seeming to me, git does it as part of how it is 'supposed to be used' which frankly sounds as mad as travelling back in time to shoot your grandfather. for these reasons - to me - using git is asking for trouble (it has caused me trouble and i switched to hg for precisely this reason). i cant reasonably recommend git to anyone... which is a shame. other than that flaw it is really quite rich and powerful and has other advantages over mercurial - including (perhaps foremost) its enormous popularity. EDIT: watch as this gets downvoted from hipster gut responses instead of thought :D

Pxtl 13y ago
Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?
- Mindless2112 13y ago
  > Do we need source-control on our source-control? That's more or less what Mercurial's changeset evolution [1] is/will be (it's not enabled by default yet). [1] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution

philliphaydon 13y ago

I don't think Mercurial is the issue here... Google Code is the issue... Didn't realise people still used that, its worse than Codeplex. Atleast use Bitbucket or something that makes it easier for people to contribute to while still keeping it with Mercurial. I've found bugs in stuff before and ended up using a different project/library for the sole reason that I found out its in Google Code and the amount of effort involved in using the site let alone raising an issue or fixing it just wasn't worth it.

leokun 13y ago
Agreed, Google Code is awful. The tree ui for browsing code is so very terrible. Browsing commits is a terrible pain. Viewing diffs is awful. And the site just looks ugly and is hard to use. I was tired of Google Code before I even knew about GitHub, I had switched to Unfuddle.

shadowmint 13y ago

I think the big summary of this post comes down to, if you don't have something like: [extensions] shelve = histedit = rebase = mq = As a git developer using hg you're going to be frustrated by all the things 'hg doesn't support'. It doesn't actually not support them, they're just (for some reason?) shipped with hg but not turned on by default.

asperous 13y ago
I'm not sure about shelve, but histedit, rebase, and mq are all history modifying extensions. Mercurial differs from git in that it prefers immutable history. The extensions are there if you really need them, not as something you should always setup imo.
- wangweij 13y ago
  Modifying local history is not dangerous, so I think mq is good. Never really used histedit and rebase.
- mrtngslr 13y ago
  I don't think this is true today. Git and Mercurial have the same basic model, which means that a commit is immutable because the identity of a commit is determined by its content. This means that you must re-create a changeset in both systems if you want to "change" it. Mercurial and Git can do this and have been doing it for years. The difference is that Git has a built-in concept of garbage collection whereas Mercurial does not. So commands that modify history in Mercurial must trigger the garbage collection (we call it strip) manually -- and they do, of course. So you wont see any big difference between 'hg rebase' and 'git rebase'. They both build new commits and remove the old commits (in Git they're removed eventually, in Mercurial they're removed immediatedly, but with a backup if you want to restore the pre-rebase state). The latest versions of Mercurial has history modification built-in: you can 'hg commit --amend' without enabling any extensions. The changeset evolution concept will take this even further and allow really cool collaborative editing of shared history.

ggchappell 13y ago

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related to a project. The project is what we are interested in: the Python or C++ or LaTeX or whatever. Git, Mercurial, etc. are just there to help us keep track of the real work. Time spent dealing with the intricacies of Git is time not spent on the primary task -- the thing that Git is supposed to help us with. Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data. I think a well-designed DVCS would be thought of in much the same way. Clearly, current DVCSs aren't. Something is very much amiss, folks.

venomsnake 13y ago
All software has its quirks. And it shows when you move out of the ultra comfort zone. If you want to drill a hole in the wall you need to take into consideration the size of the hole, the power of the drill and what are you drilling in. You cannot abstract them. And then one day someone decides to use your python code not on ReiserFS but on Ext2 that has no journaling and all hell could break loose.
migrantgeek 13y ago
If you're just storing data, your analogy is fine. It breaks down with more advanced usage like integrations which can be very difficult with large teams. I manage a VCS with thousands of developers committing to a large code base. The VC system starts to really matter and you have to understand how it handles things like conflict resolution or things can get out of hand really quickly.
gkoberger 13y ago
Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worrying about Python. Change for the sake of change is bad, but change for the sake of an improved workflow is good.

MikeTLive 13y ago

Ive been using perforce/p4 since 97. the last 8 years have been coupled with P4V and the eclipse plugins. My workflow is virtually identical to the much offered Git branching model [0]. Turn it -90deg with time left to right. Rename "develop" to "trunk". and think of "master" as being the release labels. release and feature branches are created from the build label of the previous release needing special changes that can not just go into trunk or when we want to do a minimal patch-only release. a developer makes local copy of the portions of the trunk they want/need. the server knows who has what opened for edit/add which makes checkins fast. only the change must go in. same for regular update of my local workspace. we rarely have people editing the same exact file and if we do its a simple resolve in P4V during your commit or integrate activity. So far, there are FEW benefits i see to using, or switching to, GIT: LOCAL REPOSITORY - I have the whole repo for what i am working on so can work remote easier LOCAL VERSIONING - I can create lightweight local branches that duplicate only what is required without resync of my local repo POPULARITY - all the cook kids are using it so lots of ops utilities now are built expecting it to be there under the covers. I can live without the LOCAL benefits. I have for 8 years. I worry about the third - popularity vs. merit. Where are the concrete comparisons showing all the features and functions of these solutions side by side and how they compare for a student, startup, or enterprise? EDIT: found a newer perforce:git comparison on the perforce site[1]. The LOCAL REPO/VERSIONING is available with P4SANDBOXING. I suppose modding me down is appropriate since i picked up on the POPULARITY aspect of the discussion and don't have any Hg experience. However, it seems these discussions just keep happening and there is no one-true-solution or approach. they each have merits and faults. it will be the careful consideration of these that leads to your own solution implementation. The popularity of GIT appears to be its strongest argument. EDIT2: located a GIT-v-Perforce on SO.[2] so many of the diffs, however, have been met with sandboxing It really appears the strength is in popularity - everyone else uses GIT so you should too… [0]: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ [1]: http://www.perforce.com/sites/default/files/pdf/perforce-git-comparison.pdf http://www.perforce.com/sites/default/files/pdf/perforce-git... [2]: http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave http://stackoverflow.com/questions/222782/git-vs-perforce-tw...

rallison 13y ago

eddiegroves 13y ago

Mercurial's changeset evolution sounds really powerful and seems to address the 'git rebase and force push' problems that can occur.

cpeterso 13y ago
Here's a video of a FOSDEM 2013 talk about Mercurial's changeset evolution: https://air.mozilla.org/changesets-evolution-with-mercurial/ https://air.mozilla.org/changesets-evolution-with-mercurial/

encoderer 13y ago

Having used both extensively, Git at one job, HG at the next, now Git again, I mostly have this to say: Both tools lack polish. The biggest piece of mis-information I'd like to clear up is that often times a user new to either of these makes a few mistakes and then the cold hand of death grabs them and they're certain they lost work. You never really do. In Mercurial, the permanent nature of named branches and in Git the reflog both serve you well. Seek help in such a case, because if you think you lost work, you almost certainly didn't. Edit: Also, if you're using HG and not using patch queues, you're doing it wrong. Just sayin'

eru 13y ago
I've used patch queues with hg, but there are other tools available. For example bookmarks allow you to use hg more like git. Hg with patch queues is a bit like using git and always rebasing, almost never merging. You do lose history with patch queues.

riannucci 13y ago

Author/thread starter here: Really didn't think this post would have generated as much interest as it did when I created it... :D It's a fairly enlightening thread though. Mad props to Martin for a fantastically thoughtful reply!

CmonDev 13y ago
So, you are not switching now, hopefully?

oleganza 13y ago

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are mostly about collaboration, non-stable identifiers can be very confusing.

gecko 13y ago
They can't change in a given repo unless you use history-modifying extensions. They do differ between repos. Most modern third-party tools, including Kiln, hide them by default for this reason.
- oleganza 13y ago
  Thanks for clarifying this. I haven't touched mercurial for a while.
mrtngslr 13y ago
Revision numbers are stable within a given repository. The revision number for a commit is simply the index of the commit in the changelog — nothing more. Since a changeset must come after its parent in the changelog, the revision numbers give you a topological ordering of the changesets. A topological ordering is often not unique — this is why revision numbers can differ between repositories, even if they contain exactly the same commits. Because the changelog is append-only, new commits you pull in get higher revision numbers than the existing commits. Your existing revision numbers will thus not change when you do 'hg pull' and 'hg merge'. We don't actually guarantee that revision numbers cannot change when you pull, but it's been the case until now. In any case, the stability of the revision numbers isn't why we like them — we like them since it's often easier to type 'hg histedit 12345' than 'hg histedit c38c3fdc8b93' when you've looked up a particular changeset in your (local!) repository. Hosting sites like Bitbucket and Kiln will wisely not show you revision numbers since the concept is meaningless when talking about more than one repository.

cbhl 13y ago

Part of me wonders whether this is an instance of "The Magpie Developer"[0]. I know that I personally prefer git and bzr over cvs and svn, but just ten years ago, people were all talking about how Linux had just switched to BitKeeper. I also suspect that rather than having a bikeshed-esque argument about switching between one DVCS and another, we can come up with technical solutions to enable everyone to work together. For example, when I was interning at Facebook two years ago, git-svn was used extensively to let the rank-and-file employees work with git, while still allowing chuckr to deploy off of SVN. For mercurial and git, there are services like Kiln Harmony[1] and hg-git, too. [0] http://www.codinghorror.com/blog/2008/01/the-magpie-developer.html http://www.codinghorror.com/blog/2008/01/the-magpie-develope... [1] https://secure.fogcreek.com/kiln/ https://secure.fogcreek.com/kiln/

tytso 13y ago

After reading most of the comments, and having participated on more than a few git vs. <insert random DCVS> discussions, here are what I hope are some hopefully new contributions. All systems have different tradeoffs depending the target audience that they are trying to optimize for. When comparing bzr, hg, and git, one way of thinking about it is that they differ in the size of the developer community of the project that they are trying to optimize for. The sweet spot of bzr is probably up to ten or so active developers at one time; for hg, it's probably up to around hundred or so; and for git, it's designed to scale up to several thousand active developers. Different people might want to argue over the exact breakpoints, but in terms of orders of magnitude, I think it's pretty close. One comment that was made in a thread below was that git was optimized for the people who integrate code, as opposed for those who actually produce the code --- and I think that's mostly true. Which is to say, when there was a choice between optimizing for a project which might make things easier for the integrator, or for the sub-integrator, or sub-sub-integrators (in Linux code integration happens in hierarchically; it's the only way we can scale), and making it easier for a newbie coder, git has very unapologetically optimized for the former. It's true that there are some warts which caused by legacy UI decisions which would probably have made differently if the designers could go back in time, but in my mind these are in the cateogry of things like TAB characters being significant in Makefiles; it's annoying, but practitioners very quickly learn how to deal with these warts, and they generally don't cause significant problems once people get over the startup hump. The other observation is that since choice of which DCVS gets made is generally made by project leads, who tend to be the integrators, it's not that surprising that git is very popular for them. It's also true that most project leads tend to be over-optimistic about whether their project will be the one that will grow up to have thousands of active committers (just as most startup founders are convinced that their baby will be the defeat the odds and become the wildly successful IPO whose market cap will exceed $4 billion dollars :-). Given that most projects generally don't have thousands and thousands of active developers, it might be that hg is a better choice for most projects. However, if most of your senior developers are more used to using git, because that's what they are mostly familiar with, maybe you might want to use git even though the project's scale is one that would be quite satisfied with hg. For me, the e2fsprogs project falls in that category; while the number active developers are such that hg would be fine, most of the developers are simply much more used to git, and so we use git. The third reason why git has probably become popular is because github is really good at hiding many of git's rough edges, and if people are used to github, then it might be a good set of training wheels before people graduate to using git without github's training wheels. If these three factors don't apply to your community, then maybe hg is a better choice for you. If that's true, then don't hesitate! One thing that most people forget is that while transitioning between DCVS is painful, it can be done. So if it turns out the situation changes in three or five years, it is certainly possible to convert your project from hg to git. It will be rough for a month or two, but for some projects, that might actually be better than starting with git, and then finding out that it caused some increased friction initially, and that they never needed the scale that git provides.