8 ms·

I used Git for a couple of years then changed to Mercurial and have never looked back, except now and then to wonder at the size of the crowd that has gathered

I used Git for a couple of years then changed to Mercurial and have never looked back, except now and then to wonder at the size of the crowd that has gathered around Git, driven in no small part by the success of github (which is not a bad thing!) Git is an entirely appropriate tool for managing as something as large and complex as the Linux kernel, but I'm doing much simpler stuff, and Mercurial is simpler and has a much shallower learning curve. I'd recommend it unequivocally to teams of modest size working on average applications. The state of git documentation is much better today than it was five or six years ago, so maybe its complexity is less of a big deal, but so far I've not encountered any issues with Mercurial that make me think "If only I was using git this would be easy!" What I found with git was I had to maintain a fairly complex mental model of the current state of affairs, and because I'm not very intelligent that took quite a bit of effort. With Mercurial the model is much simpler, so I can spend more of my very limited attention on writing code. It's quite possible that I simply never took the time to learn git properly, but with Mercurial I didn't have to.

Someone1234 12y ago
I won't comment on Mercurial because I don't know anything about it. I really do feel like Git is appropriate for small projects. The .git store is incredibly small (because it only stores changes) and quite simple when you get used to it. You will only only need to use a tiny subset of Git's functionality (or, heck, just the Github web-UI if you wish). I think the hardest thing about Git for big and small teams is getting used to the mental model of Git (branching, merging, master, etc). Once you get it down you realise that Git is less complex, not more... PS - This comment is mostly in reply to the implication that Git is a better tool for large and complex projects like the Linux Kernel. PPS - Mercurial might be a better tool yet still for small projects, I don't know enough about Mercurial to have a qualified opinion either way.
- acveilleux 12y ago
  For all intent and purpose, git and hg are fairly equivalent. In day to day usage, the two big differences are: 1. Local branches Git has them, mercurial doesn't really. Mercurial wants you to use a lightweight clone (copy-on-write with hard links) instead. Lots of mercurial extensions deal with this however. The lack of rebase in stock hg is probably directly driven by the lack of local branches that don't get pushed upstream by default. 2. Committing code Mercurial, without extensions, doesn't have the git shelf. With extensions there's a few competing options like MQ, Shelve or Evolve. Both these points make hg easier to learn (branch == clone is very easy to wrap your head around, commit behaves basically like svn/cvs).
  - ngoldbaum 12y ago
    For several years now Mercurial has had bookmarks in core, which are analogous to git's local branches. It's also worth pointing out that many of the extensions you referred to (rebase, shelve) are bundled with core Mercurial and need only a one-line addition to a configuration file to turn them on. Extensions bundled with core Mercurial have the same level support and backward compatibility guarantees as the rest of Mercurial. Part of Mercurial's command line philosophy is to not include obvious foot-guns (like the ability to rewrite history) in the default version.
    - tacticus 12y ago
      And for several years bookmarks have been unfortunately missing in unfortunately common linux distributions.
      - ngoldbaum 12y ago
        It's quite easy to build mercurial from source. That said I understand the pain of being on locked down ancient linux installs with no access to compilers.
  - imakesnowflakes 12y ago
    >Mercurial wants you to use a lightweight clone.... You can make a named branch and make it private so that it wont be pushed automatically or you can create a bookmark and mark the changeset as private, so that it wont get pushed automatically OR you can create a local clone, completely isolated from the origin repo. The difference between git branches and Mercurial branches is a bit of a conceptual one. Git has 'user' branches, where a branch corresponds to the work of a user. Mercurial has 'feature' branches, where each named branch (is supposed to) correspond to a feature. I think This is the one of the reasons some Git users are sometimes so turned off when they see Mercurial branching model. And to me, I would like a project as a sum of its feature branches. But I can imagine why this might not be optimal for a something like Linux kernel. But for most projects, I think feature branches are more valuable than the user branchs of git. >Mercurial, without extensions, doesn't have the git shelf. Shelve extension is bundled, enabling is just a matter of turning on a flag in the .hgrc configuration file...
- LukeShu 12y ago
  > The .git store is incredibly small (because it only > stores changes) git stores a complete copy of each revision, not changesets. (Well, it is my understanding that a .pack compressed archive of objects may store some of the objects as changesets, but that's not the general case)
  - stormbrew 12y ago
    When git repacks[1], which it does periodically (but not on every commit), it will store objects in as compact a form that it can, which basically means that it looks for root objects that it can delta a given object against so it stores each chunk of text as few times as possible. What it doesn't do is store files as deltas explicitly against the previous or next revision of that file. It attempts to find a best fit dynamically. It also does something like this packing procedure when responding to a fetch to avoid sending more data than it needs to, btw. [1] https://www.kernel.org/pub/software/scm/git/docs/git-repack.html https://www.kernel.org/pub/software/scm/git/docs/git-repack....
  - Someone1234 12y ago
    It stores a complete copy of the file, not a complete copy of the entire repository. So it keeps your .git fairly light weight since only changed files have duplicate copies. Essentially it is not line level, but file level, rather than complete repository level (e.g. like Team Foundation is).
    - josteink 12y ago
      > So it keeps your .git fairly light weight (... compared to ...) Team Foundation And you can tell from how the product is being used. Where I work, we use TFS and you literally need to have committee meetings before a new branch is made. You need to agree on long term strategies, you need to agree on branch hierarchy (because TFS cannot merge without one), you need to replicate all-the-things(tm) for your new branch, you need to adjust your versioning-strategy for this branch, and possibly future branches which may come and may not ever collide with this one, because TFS branches are massive and carved in stone. They are forever. Etc etc. You never branch more than once a year. In the world of TFS, doing such would be madness, haphazard. Or at least you would need a full team doing nothing but branching and merging and integration. And good luck trying to find qualified people willing to have that as their day-job. With git you branch every single time it makes sense, usually several times a day. And your life is nicer because of it. It's funny how such technical decisions results in such huge and enormous visible changes to how a product is being used. Somewhere deep in Microsoft there are probably one or more engineers crying right now seeing the effects of their (back then) seemingly innocent decision, as they themselves are forced to deal with TFS in their daily work and they see how nice the gitters have it.
- Aga 12y ago
  For me Git has also worked very well for small projects. I actually learned it initially by using it for my masters thesis. One correction: Git does not store changes at all. It stores all the versions of files as separate "blobs". What keeps .git small, is that Git compresses the object database to pack-files. "git gc" does this for you. Pro Git has a great chapter about how Gits internals work: https://git-scm.herokuapp.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.herokuapp.com/book/en/v2/Git-Internals-Plumb... This picture sums the model nicely: https://git-scm.herokuapp.com/book/en/v2/book/10-git-internals/images/data-model-4.png https://git-scm.herokuapp.com/book/en/v2/book/10-git-interna... For me studying Git internals has been a good lesson in software design. Git's core is very simple, yet somehow that makes it a really versatile tool.
- jebblue 12y ago
  Git rocks for small to medium sized projects, never tried it on a large one but Linus made it for the kernel so that would not worry me either. Going into a directory and easily creating a repo there, where I need it, is great. Canonical did something similar with their Bazaar tool.
imakesnowflakes 12y ago
Mercurial is not only simpler, but also has got really powerful features like revsets. http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets I have tried to switch to git multiple times. Every time, I keep coming back to Mercurial. The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. Because of this, I experience a big mental block when I try to reason about something. With Mercurial this is very much easier. And if you are using a DVCS to any capacity you ll have to do this often. Another great thing about Mercurial is how easy to get help about stuff. You can head to the IRC chat room and can have a very good chance of catching one of the developers who, in my experience, were very helpful...
- jordigh 12y ago
  > Mercurial is not only simpler, but also has got really powerful features like revsets. Revsets together with templates can be used to build custom commands: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... There are also filesets that work similarly for doing queries on files (hg help filesets).
- stormbrew 12y ago
  > The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. This is a frustrating thing about how people tend to talk negatively about git. I think what you mean is "not named in a way I'm used to," because there's nothing nonsensical about this naming at all, and it's actually an incredibly simple and lightweight way to reason about naming things in version control (imo, I suppose). And it permeates basically every level of how git organizes information in a pretty darn uniform way. To me mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. That'd just be admitting that I stopped thinking about it when it was strange and unfamiliar to me.
  - imakesnowflakes 12y ago
    >I think what you mean is "not named in a way I'm used to,".. Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'. >To me Mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. I don't know what you mean by 'several plugins to do branch like things'. Isn't it more frustrating that people complain about a tool because they have to enable some advanced stuff by configuration. But I agree that Mercurial is actually complex than Git, because it provides more options to the user. So the complexity of Mercurial is a side effect of it being more powerful IMHO. So the point is I say, naming a 'pointer to a commit' as branch, is nonsensical because it goes against our notion of the word 'Branch' from real life. It adds unnecessary burden for a human being trying to think in the language of the tool, without actually making the tool more powerful. Git could have been as powerful as it is now even if it had named things better, Right?
jibsen 12y ago
I moved from the other way from Mercurial to Git a while back. I started using Mercurial because the basic interface and operations appeared more natural to me. Also, at least at the time, the Windows support was better in Mercurial. After working with some repos using Git, I fell in love with the staging area, and the ability to selectively stage parts of files. I am sure Mercurial has something similar, but it was built into Git. The only thing that bugs me is that the Windows port appears to be stuck at 1.9.5 (yes, I know it's open-source so I should go fix it instead of complaining).
- jordigh 12y ago
  > The only thing that bugs me is that the Windows port appears to be stuck at 1.9.5 What? What gave you that impression? That's a really old version. Here's the last 3.3 Windows build: http://bitbucket.org/tortoisehg/files/downloads/tortoisehg-3.3.3-x64.msi http://bitbucket.org/tortoisehg/files/downloads/tortoisehg-3... This was from the downloads page: http://mercurial.selenic.com/downloads http://mercurial.selenic.com/downloads Edit: Oh, crap, I completely misread that. You were talking about the git Windows version. Oh well. Mercurial Windows versions are staying quite up-to-date, thanks to the tireless work of Steve Borho.
  - ngoldbaum 12y ago
    I think they're talking about the git port for windows.
- skeoh 12y ago
  Yes! Partial staging of files is amazing and I miss it sorely when I use hg. There must be a way to do it.
  - jordigh 12y ago
    Use crecord. We're working on moving it into core: https://bitbucket.org/edgimar/crecord/overview https://bitbucket.org/edgimar/crecord/overview If you want a "staging area" just use a temporary commit and keep ammending it with `hg crecord --amend`. There really is no difference between a commit and a staging area except the name. If you're afraid of pushing your WIP commit, use `hg crecord --secret` or `hg commit --secret` so that your commit will be in the secret phase and won't be pushed until you declare it draft with `hg phase --draft`.
rqebmm 12y ago
Where I land is that mercurial is a better tool, but git is a better platform. As a result, better tools have been built on top of git than mercurial (like github). As a result, git at some point became the standard.

Someone1234 12y ago

I won't comment on Mercurial because I don't know anything about it. I really do feel like Git is appropriate for small projects. The .git store is incredibly small (because it only stores changes) and quite simple when you get used to it. You will only only need to use a tiny subset of Git's functionality (or, heck, just the Github web-UI if you wish). I think the hardest thing about Git for big and small teams is getting used to the mental model of Git (branching, merging, master, etc). Once you get it down you realise that Git is less complex, not more... PS - This comment is mostly in reply to the implication that Git is a better tool for large and complex projects like the Linux Kernel. PPS - Mercurial might be a better tool yet still for small projects, I don't know enough about Mercurial to have a qualified opinion either way.

acveilleux 12y ago
For all intent and purpose, git and hg are fairly equivalent. In day to day usage, the two big differences are: 1. Local branches Git has them, mercurial doesn't really. Mercurial wants you to use a lightweight clone (copy-on-write with hard links) instead. Lots of mercurial extensions deal with this however. The lack of rebase in stock hg is probably directly driven by the lack of local branches that don't get pushed upstream by default. 2. Committing code Mercurial, without extensions, doesn't have the git shelf. With extensions there's a few competing options like MQ, Shelve or Evolve. Both these points make hg easier to learn (branch == clone is very easy to wrap your head around, commit behaves basically like svn/cvs).
- ngoldbaum 12y ago
  For several years now Mercurial has had bookmarks in core, which are analogous to git's local branches. It's also worth pointing out that many of the extensions you referred to (rebase, shelve) are bundled with core Mercurial and need only a one-line addition to a configuration file to turn them on. Extensions bundled with core Mercurial have the same level support and backward compatibility guarantees as the rest of Mercurial. Part of Mercurial's command line philosophy is to not include obvious foot-guns (like the ability to rewrite history) in the default version.
  - tacticus 12y ago
    And for several years bookmarks have been unfortunately missing in unfortunately common linux distributions.
    - ngoldbaum 12y ago
      It's quite easy to build mercurial from source. That said I understand the pain of being on locked down ancient linux installs with no access to compilers.
- imakesnowflakes 12y ago
  >Mercurial wants you to use a lightweight clone.... You can make a named branch and make it private so that it wont be pushed automatically or you can create a bookmark and mark the changeset as private, so that it wont get pushed automatically OR you can create a local clone, completely isolated from the origin repo. The difference between git branches and Mercurial branches is a bit of a conceptual one. Git has 'user' branches, where a branch corresponds to the work of a user. Mercurial has 'feature' branches, where each named branch (is supposed to) correspond to a feature. I think This is the one of the reasons some Git users are sometimes so turned off when they see Mercurial branching model. And to me, I would like a project as a sum of its feature branches. But I can imagine why this might not be optimal for a something like Linux kernel. But for most projects, I think feature branches are more valuable than the user branchs of git. >Mercurial, without extensions, doesn't have the git shelf. Shelve extension is bundled, enabling is just a matter of turning on a flag in the .hgrc configuration file...
LukeShu 12y ago
> The .git store is incredibly small (because it only > stores changes) git stores a complete copy of each revision, not changesets. (Well, it is my understanding that a .pack compressed archive of objects may store some of the objects as changesets, but that's not the general case)
- stormbrew 12y ago
  When git repacks[1], which it does periodically (but not on every commit), it will store objects in as compact a form that it can, which basically means that it looks for root objects that it can delta a given object against so it stores each chunk of text as few times as possible. What it doesn't do is store files as deltas explicitly against the previous or next revision of that file. It attempts to find a best fit dynamically. It also does something like this packing procedure when responding to a fetch to avoid sending more data than it needs to, btw. [1] https://www.kernel.org/pub/software/scm/git/docs/git-repack.html https://www.kernel.org/pub/software/scm/git/docs/git-repack....
- Someone1234 12y ago
  It stores a complete copy of the file, not a complete copy of the entire repository. So it keeps your .git fairly light weight since only changed files have duplicate copies. Essentially it is not line level, but file level, rather than complete repository level (e.g. like Team Foundation is).
  - josteink 12y ago
    > So it keeps your .git fairly light weight (... compared to ...) Team Foundation And you can tell from how the product is being used. Where I work, we use TFS and you literally need to have committee meetings before a new branch is made. You need to agree on long term strategies, you need to agree on branch hierarchy (because TFS cannot merge without one), you need to replicate all-the-things(tm) for your new branch, you need to adjust your versioning-strategy for this branch, and possibly future branches which may come and may not ever collide with this one, because TFS branches are massive and carved in stone. They are forever. Etc etc. You never branch more than once a year. In the world of TFS, doing such would be madness, haphazard. Or at least you would need a full team doing nothing but branching and merging and integration. And good luck trying to find qualified people willing to have that as their day-job. With git you branch every single time it makes sense, usually several times a day. And your life is nicer because of it. It's funny how such technical decisions results in such huge and enormous visible changes to how a product is being used. Somewhere deep in Microsoft there are probably one or more engineers crying right now seeing the effects of their (back then) seemingly innocent decision, as they themselves are forced to deal with TFS in their daily work and they see how nice the gitters have it.
Aga 12y ago
For me Git has also worked very well for small projects. I actually learned it initially by using it for my masters thesis. One correction: Git does not store changes at all. It stores all the versions of files as separate "blobs". What keeps .git small, is that Git compresses the object database to pack-files. "git gc" does this for you. Pro Git has a great chapter about how Gits internals work: https://git-scm.herokuapp.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.herokuapp.com/book/en/v2/Git-Internals-Plumb... This picture sums the model nicely: https://git-scm.herokuapp.com/book/en/v2/book/10-git-internals/images/data-model-4.png https://git-scm.herokuapp.com/book/en/v2/book/10-git-interna... For me studying Git internals has been a good lesson in software design. Git's core is very simple, yet somehow that makes it a really versatile tool.
jebblue 12y ago
Git rocks for small to medium sized projects, never tried it on a large one but Linus made it for the kernel so that would not worry me either. Going into a directory and easily creating a repo there, where I need it, is great. Canonical did something similar with their Bazaar tool.

imakesnowflakes 12y ago

Mercurial is not only simpler, but also has got really powerful features like revsets. http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets I have tried to switch to git multiple times. Every time, I keep coming back to Mercurial. The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. Because of this, I experience a big mental block when I try to reason about something. With Mercurial this is very much easier. And if you are using a DVCS to any capacity you ll have to do this often. Another great thing about Mercurial is how easy to get help about stuff. You can head to the IRC chat room and can have a very good chance of catching one of the developers who, in my experience, were very helpful...

jordigh 12y ago
> Mercurial is not only simpler, but also has got really powerful features like revsets. Revsets together with templates can be used to build custom commands: http://jordi.inversethought.com/blog/customising-mercurial-like-a-pro/ http://jordi.inversethought.com/blog/customising-mercurial-l... There are also filesets that work similarly for doing queries on files (hg help filesets).
stormbrew 12y ago
> The most difficulty I have with git is the non nonsensical naming of concepts. For eg, A branch is a pointer to a commit. This is a frustrating thing about how people tend to talk negatively about git. I think what you mean is "not named in a way I'm used to," because there's nothing nonsensical about this naming at all, and it's actually an incredibly simple and lightweight way to reason about naming things in version control (imo, I suppose). And it permeates basically every level of how git organizes information in a pretty darn uniform way. To me mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. That'd just be admitting that I stopped thinking about it when it was strange and unfamiliar to me.
- imakesnowflakes 12y ago
  >I think what you mean is "not named in a way I'm used to,".. Of course, that is the whole point of naming something sensibility..Just, for example, imagine how hard it would be if you have to learn/work in a version of C that calls pointers as 'branches'. >To me Mercurial's two kinds of built-in branches and several plugins to do branch-like things is much more complex, but I still wouldn't call it nonsensical. I don't know what you mean by 'several plugins to do branch like things'. Isn't it more frustrating that people complain about a tool because they have to enable some advanced stuff by configuration. But I agree that Mercurial is actually complex than Git, because it provides more options to the user. So the complexity of Mercurial is a side effect of it being more powerful IMHO. So the point is I say, naming a 'pointer to a commit' as branch, is nonsensical because it goes against our notion of the word 'Branch' from real life. It adds unnecessary burden for a human being trying to think in the language of the tool, without actually making the tool more powerful. Git could have been as powerful as it is now even if it had named things better, Right?

jibsen 12y ago

I moved from the other way from Mercurial to Git a while back. I started using Mercurial because the basic interface and operations appeared more natural to me. Also, at least at the time, the Windows support was better in Mercurial. After working with some repos using Git, I fell in love with the staging area, and the ability to selectively stage parts of files. I am sure Mercurial has something similar, but it was built into Git. The only thing that bugs me is that the Windows port appears to be stuck at 1.9.5 (yes, I know it's open-source so I should go fix it instead of complaining).

jordigh 12y ago
> The only thing that bugs me is that the Windows port appears to be stuck at 1.9.5 What? What gave you that impression? That's a really old version. Here's the last 3.3 Windows build: http://bitbucket.org/tortoisehg/files/downloads/tortoisehg-3.3.3-x64.msi http://bitbucket.org/tortoisehg/files/downloads/tortoisehg-3... This was from the downloads page: http://mercurial.selenic.com/downloads http://mercurial.selenic.com/downloads Edit: Oh, crap, I completely misread that. You were talking about the git Windows version. Oh well. Mercurial Windows versions are staying quite up-to-date, thanks to the tireless work of Steve Borho.
- ngoldbaum 12y ago
  I think they're talking about the git port for windows.
skeoh 12y ago
Yes! Partial staging of files is amazing and I miss it sorely when I use hg. There must be a way to do it.
- jordigh 12y ago
  Use crecord. We're working on moving it into core: https://bitbucket.org/edgimar/crecord/overview https://bitbucket.org/edgimar/crecord/overview If you want a "staging area" just use a temporary commit and keep ammending it with `hg crecord --amend`. There really is no difference between a commit and a staging area except the name. If you're afraid of pushing your WIP commit, use `hg crecord --secret` or `hg commit --secret` so that your commit will be in the secret phase and won't be pushed until you declare it draft with `hg phase --draft`.

rqebmm 12y ago

Where I land is that mercurial is a better tool, but git is a better platform. As a result, better tools have been built on top of git than mercurial (like github). As a result, git at some point became the standard.