5 ms·

Why a small team chose Mercurial.

37 points by atrain34 16y ago

After using git and then using Mercurial, it was clear that Mercurial was a better fit for our company, how we develop. For educated people on git/hg, these might be a surprise. But the people still considering git or hg its a good look.

jdludlow 16y ago
Before this devolves into a git versus hg holy war by people who never read the linked blog post, I'll point out that they chose hg over svn. It's mainly a cheerleader piece for DVCS with the git versus hg choice being a minor point.
- atrain34 16y ago
  yes, please read the linked blog post. they used both hg and git quite a bit but found hg easier to host, use and move over from subversion (convert repos but also command line). so yes, cheerleader piece you are right on that. not much cheerleading for hg these days.
  - jorgem 16y ago
    >> not much cheerleading for hg these days. Joel Spolsky seems to like it: http://hginit.com/ http://hginit.com/
    - foljs 16y ago
      HG: liked by the guy that gave us Visual Basic for applications, some nice essays, tons of tedious advice on how to hire the top programmers, a ho-hum bug tracking system and an abomination of a meta-language for creating web-apps, both created by said "top" programmers.
- ams6110 16y ago
  I switched from svn to hg for personal stuff too. Like the author of the blog post, I looked at git and found that it was nonintuitive. hg commands are close enough to svn commands that I felt more comfortable sooner. I don't really get the big issue with branches in svn though. Branches and tags are "cheap" operations in svn, and making personal branches, etc. was something I used to do. Merging back into trunk was never a huge issue either. Maybe I've been lucky; also our team was not very big and different people weren't often working on the same source files at the same time.
dlsspy 16y ago
This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental difference here. I don't want every failed, unbuildable, safety-net commit making it into my project history. I want it to be possible for people to understand change. For example, here are the last few commits from my primary work project: http://pastebin.com/BiNpP08s http://pastebin.com/BiNpP08s In a week from now, will you need to see the four different attempts it took to get that last change right? If so, you can always follow the code review link and see the discussion that went on there and how it shaped into that file change, but anyone who makes actual good use of their project history will get frustrated pretty quickly at thought-free changes.
- Rusky 16y ago
  The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history. The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history. If you just need to save some partially working state, etc. you can use patch queues- They make much more sense here.
  - randallsquared 16y ago
    I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but: 1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter. 2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit messages to tie commits to tickets in your bug tracker, this can make code show up on the wrong ticket, or not at all, which is quite confusing for a later maintainer.
indspenceable 16y ago
Pretty good; liked that they didn't just say "HG GOOD, GIT BAD". I'm confused about the git learning curve though; I started using git on my own this summer, and I was able to immediately pick up the commands I needed to get by literally the day I started. I'll admit I don't have to host repositories, like they would in for their company; but for simply using git as a developer it was very painless.
- gecko 16y ago
  Having taught people both systems, I will assert, based on my personal experience, that while some developers can certainly pick up Git relatively painlessly, picking up Mercurial objectively requires less time, and leaves users less likely to get into a state that they are unsure how to exit. This is purely based on my own personal experience, and I have not scientifically codified the learning time in double-blind testing or whatnot, but it's a data point based on more than just my own personal meandering attempt to learn the two tools. EDIT: I am not making a value judgment here. It's harder to learn to fly a plane than drive a car, but that hardly makes the car better than the plane or vice-versa. It's just a recognition that their learning curves aren't identical.
  - Xurinos 16y ago
    Having introduced git to a few groups (and some hg), I found that the main thing that makes hg easier to learn is that hg mimics some of the same names of commands as cvs/svn. However, once they understand what is going on in git, the aha moments start to show up, and the really complicated stuff becomes easy.
- Legion 16y ago
  Some of git's learning curve reputation is historical. Some good effort as been put into making git less arcane.
epynonymous 16y ago
altogether a means to an end, mercurial and git are both good. i personally use mercurial. have worked with git in the past and was having trouble with the gerrit web front end and the fact that it required java. i also use bitbucket and since having been bought by atlassian, was able to get lots of free private repositories. i think some people mentioned that they accidentally left cookie secrets in their code on a public github project. i'm still too early in development to get into the perceived branching woes that others are talking about, but i'll let you know when i get there.
- ldh 16y ago
  The fun thing about lightweight, painless branching is that once you start to incorporate that into your workflow, it's never too early in a project to use it. Lately every new feature or fix I start to work on begins its life in a topic branch. You never know when you're going to be interrupted or need to switch contexts to work on something else (or even just scrap the whole idea) so having your repository mirror your mental process in a completely seamless way is invaluable.
pacemkr 16y ago
I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches. Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way to do this in hg. [1] Deleting a branch is not a fundamental concept in hg, and so the advice is to create a new local "clone" of the entire repo. [2] Great, now you have to change the config files for your dev environment to point to a new folder just so you can test out crazy feature. Also, by default all your branches get pushed (although hg will complain about creating remote branches). In practice, all this turned "branching" into an expensive concept in my mind. That's bad, very bad. I still prefer the hg elegance and ui to git -- even the output of "hg st" vs "git status" tells a great deal about the philosophy behind both. However, I think hg got branching wrong and that is a fundamental flaw that no amount of elegance at the UI level can compensate for. I remember when I was making my first choice between hg and git and the advice was "they're pretty much the same, pick one." I think that advice is incorrect based on what I've said above. [1] http://mercurial.selenic.com/wiki/LocalbranchExtension http://mercurial.selenic.com/wiki/LocalbranchExtension [2] http://mercurial.selenic.com/wiki/PruningDeadBranches http://mercurial.selenic.com/wiki/PruningDeadBranches
- schumihan 16y ago
  I use patch queue[1] to manage these short lived branch, and it works for my purpose. You just pop the patches and delete them all when you want to prunge the branch. It also make it easy for others to review your code. If these short-lived branch will be merged back shortly. Bookmark is another alternatives. [1] http://mercurial.selenic.com/wiki/MqExtension http://mercurial.selenic.com/wiki/MqExtension [2] http://mercurial.selenic.com/wiki/BookmarksExtension http://mercurial.selenic.com/wiki/BookmarksExtension
  - pacemkr 16y ago
    I'm aware of both. Personally I find this to be an inferior solution. Using a patch queue as a local branch just feels wrong. Neither is using bookmarks an effective solution. Both solution make the decision to branch a much more deliberate process, and in the end you still don't get a branch that is equal to its peers. As the result, in hg, you have to decide in advance "what kind of branch" it will be -- or you have to get in the habit of using mq's for everything -- and this just not a natural experience especially for a DVCS where branching is just fundamental.

37 points by atrain34 16y ago

jdludlow 16y ago

Before this devolves into a git versus hg holy war by people who never read the linked blog post, I'll point out that they chose hg over svn. It's mainly a cheerleader piece for DVCS with the git versus hg choice being a minor point.

atrain34 16y ago
yes, please read the linked blog post. they used both hg and git quite a bit but found hg easier to host, use and move over from subversion (convert repos but also command line). so yes, cheerleader piece you are right on that. not much cheerleading for hg these days.
- jorgem 16y ago
  >> not much cheerleading for hg these days. Joel Spolsky seems to like it: http://hginit.com/ http://hginit.com/
  - foljs 16y ago
    HG: liked by the guy that gave us Visual Basic for applications, some nice essays, tons of tedious advice on how to hire the top programmers, a ho-hum bug tracking system and an abomination of a meta-language for creating web-apps, both created by said "top" programmers.
ams6110 16y ago
I switched from svn to hg for personal stuff too. Like the author of the blog post, I looked at git and found that it was nonintuitive. hg commands are close enough to svn commands that I felt more comfortable sooner. I don't really get the big issue with branches in svn though. Branches and tags are "cheap" operations in svn, and making personal branches, etc. was something I used to do. Merging back into trunk was never a huge issue either. Maybe I've been lucky; also our team was not very big and different people weren't often working on the same source files at the same time.

dlsspy 16y ago

This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental difference here. I don't want every failed, unbuildable, safety-net commit making it into my project history. I want it to be possible for people to understand change. For example, here are the last few commits from my primary work project: http://pastebin.com/BiNpP08s http://pastebin.com/BiNpP08s In a week from now, will you need to see the four different attempts it took to get that last change right? If so, you can always follow the code review link and see the discussion that went on there and how it shaped into that file change, but anyone who makes actual good use of their project history will get frustrated pretty quickly at thought-free changes.

Rusky 16y ago
The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history. The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history. If you just need to save some partially working state, etc. you can use patch queues- They make much more sense here.
- randallsquared 16y ago
  I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but: 1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter. 2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit messages to tie commits to tickets in your bug tracker, this can make code show up on the wrong ticket, or not at all, which is quite confusing for a later maintainer.

indspenceable 16y ago

Pretty good; liked that they didn't just say "HG GOOD, GIT BAD". I'm confused about the git learning curve though; I started using git on my own this summer, and I was able to immediately pick up the commands I needed to get by literally the day I started. I'll admit I don't have to host repositories, like they would in for their company; but for simply using git as a developer it was very painless.

gecko 16y ago
Having taught people both systems, I will assert, based on my personal experience, that while some developers can certainly pick up Git relatively painlessly, picking up Mercurial objectively requires less time, and leaves users less likely to get into a state that they are unsure how to exit. This is purely based on my own personal experience, and I have not scientifically codified the learning time in double-blind testing or whatnot, but it's a data point based on more than just my own personal meandering attempt to learn the two tools. EDIT: I am not making a value judgment here. It's harder to learn to fly a plane than drive a car, but that hardly makes the car better than the plane or vice-versa. It's just a recognition that their learning curves aren't identical.
- Xurinos 16y ago
  Having introduced git to a few groups (and some hg), I found that the main thing that makes hg easier to learn is that hg mimics some of the same names of commands as cvs/svn. However, once they understand what is going on in git, the aha moments start to show up, and the really complicated stuff becomes easy.
Legion 16y ago
Some of git's learning curve reputation is historical. Some good effort as been put into making git less arcane.

epynonymous 16y ago

altogether a means to an end, mercurial and git are both good. i personally use mercurial. have worked with git in the past and was having trouble with the gerrit web front end and the fact that it required java. i also use bitbucket and since having been bought by atlassian, was able to get lots of free private repositories. i think some people mentioned that they accidentally left cookie secrets in their code on a public github project. i'm still too early in development to get into the perceived branching woes that others are talking about, but i'll let you know when i get there.

ldh 16y ago
The fun thing about lightweight, painless branching is that once you start to incorporate that into your workflow, it's never too early in a project to use it. Lately every new feature or fix I start to work on begins its life in a topic branch. You never know when you're going to be interrupted or need to switch contexts to work on something else (or even just scrap the whole idea) so having your repository mirror your mental process in a completely seamless way is invaluable.

pacemkr 16y ago

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches. Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way to do this in hg. [1] Deleting a branch is not a fundamental concept in hg, and so the advice is to create a new local "clone" of the entire repo. [2] Great, now you have to change the config files for your dev environment to point to a new folder just so you can test out crazy feature. Also, by default all your branches get pushed (although hg will complain about creating remote branches). In practice, all this turned "branching" into an expensive concept in my mind. That's bad, very bad. I still prefer the hg elegance and ui to git -- even the output of "hg st" vs "git status" tells a great deal about the philosophy behind both. However, I think hg got branching wrong and that is a fundamental flaw that no amount of elegance at the UI level can compensate for. I remember when I was making my first choice between hg and git and the advice was "they're pretty much the same, pick one." I think that advice is incorrect based on what I've said above. [1] http://mercurial.selenic.com/wiki/LocalbranchExtension http://mercurial.selenic.com/wiki/LocalbranchExtension [2] http://mercurial.selenic.com/wiki/PruningDeadBranches http://mercurial.selenic.com/wiki/PruningDeadBranches

schumihan 16y ago
I use patch queue[1] to manage these short lived branch, and it works for my purpose. You just pop the patches and delete them all when you want to prunge the branch. It also make it easy for others to review your code. If these short-lived branch will be merged back shortly. Bookmark is another alternatives. [1] http://mercurial.selenic.com/wiki/MqExtension http://mercurial.selenic.com/wiki/MqExtension [2] http://mercurial.selenic.com/wiki/BookmarksExtension http://mercurial.selenic.com/wiki/BookmarksExtension
- pacemkr 16y ago
  I'm aware of both. Personally I find this to be an inferior solution. Using a patch queue as a local branch just feels wrong. Neither is using bookmarks an effective solution. Both solution make the decision to branch a much more deliberate process, and in the end you still don't get a branch that is equal to its peers. As the result, in hg, you have to decide in advance "what kind of branch" it will be -- or you have to get in the habit of using mq's for everything -- and this just not a natural experience especially for a DVCS where branching is just fundamental.