6 ms·

I still wonder what are the advantages of git over mercurial.

by jokoon 12y ago

mhartl 12y ago
Perhaps the main advantage is that Git has won the mindshare war vs. Mercurial, and there are benefits to using what everyone else is using. Indeed, über-hacker Eric Raymond mentioned as recently as yesterday that he supports git even though he wishes hg had won instead. [1] [1]: http://esr.ibiblio.org/?p=6476 http://esr.ibiblio.org/?p=6476
Peaker 12y ago
Out of the box support for rebase and interactive rebase. Interactive commands to stage/unstage/commit. Better underlying data format: Checking out any version in history is a cheap operation. And generally better acceptance of the tool/wider familiarity.
- rbehrends 12y ago
  > Out of the box support for rebase and interactive rebase. Interactive commands to stage/unstage/commit. Mercurials has those features, too, if you desire them (whether they're a good thing to have is a different argument). These features are not enabled by default because they can either lose history (rebase) or are complicated for new users (or are of dubious benefit). You're probably confused by the fact that they're called extensions. I've always argued that the term "extensions" is misleading in this case. In actual fact, the bundled extensions are modules of the core system, which are maintained and supported at the same level as "core" Mercurial. See, e.g., this discussion: http://www.selenic.com/pipermail/mercurial/2013-November/046315.html http://www.selenic.com/pipermail/mercurial/2013-November/046... > Better underlying data format: Checking out any version in history is a cheap operation. Git actually has some serious scalability problems in places and no good way to overcome them, since the storage format is hardcoded. For example: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02015.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02... I can't think of any version control system where checking out any version in history isn't fundamentally a cheap operation, either. This is not a Git-specific thing.
  - Peaker 12y ago
    > are not enabled by default because they can either lose history (rebase) or are complicated for new users (or are of dubious benefit). Yet for me and many users, this means we cannot go to any coworker's terminal and use those features, many of us can no longer live without. > Git actually has some serious scalability problems in places and no good way to overcome them How so? You can upgrade the format in new versions (perhaps some abstractions to make it easy are missing, but there's enough development effort behind git that it doesn't have to be easy). I don't think hg is more scalable than git. > I can't think of any version control system where checking out any version in history isn't fundamentally a cheap operation, either. This is not a Git-specific thing. I read that hg uses some sort of a linear-append history format, meaning that going back to past versions is O(distance) in time. Is that false?
    - rbehrends 12y ago
      > I read that hg uses some sort of a linear-append history format, meaning that going back to past versions is O(distance) in time. Is that false? This is pretty much completely false. Mercurial stores repository data (except for the parts that relate to the current working tree) in revlog format [1], which is specifically designed to allow retrieval of arbitary revisions in time proportional to the file size (modulo what seek times spinning platter disks may impose for uncached sectors). The revlog format is designed to be append-only, but that actually is done to keep things fast by enabling random access based on an index; it does not lead to O(history size) operations. > I don't think hg is more scalable than git. Git actually has made a number of conscious design decisions that limit its scalability that other versions haven't made. To understand that this is largely intentional and not likely to go away in any meaningful way anytime soon, consider this post [2] by Linus Torvalds on the Git mailing list in 2007 regarding the "git blame" problem. There is a surprising willingness there to sacrifice usability and scalability on the altar of Git's super-simple repository format. Git's storage format is essentially a very simple transactional key-value store. While that has the benefit of allowing for a simple and robust implementation, it also makes certain operations more expensive than they need be (such as "git blame"). Some things Git can't even do, because it lacks the necessary metadata (such as avoiding spurious conflicts from first cherry-picking from a branch and later merging with the same branch). Others inherently require O(history length) or O(repository size) operations. Git was designed by people who considered a repository with a couple of hundred MB a big project; Git really starts breaking down once you hit the 1GB barrier. Checkout the gcc repository (about 1.4GB), for example, then do "git gc", and take a coffee break, because it'll take a couple of minutes. Somewhat famously, Facebook documented [3] some of their troubles with making Git scale. Git, unlike Bzr or Mercurial, does not have a pluggable storage layer that can be used to easily ameliorate these shortcomings. Bzr [4], as an extreme, can cheerfully operate on a remote repository in the exact same way as a local one, because it treats local file storage vs. ssh vs. http(s) vs. sftp etc. just as different implementations of the storage layer. Facebook extended Mercurial [5] to accomplish largely the same goal. Note that the above does not mean "Git sucks". For the most part, Git is a fine version control system, but where scalability is concerned, I'd pick a number of other VCSs first (and which is, frankly, why a lot of shops still use SVN over either Git or Mercurial; SVN may be more cumbersome to use, but it is a known quantity when it comes to handling large repositories). Git in particular is too much written like the typical C program, with a lot of concern for keeping constants low, but often with little concern for asymptotic worst-case complexity or extensibility. > Yet for me and many users, this means we cannot go to any coworker's terminal and use those features, many of us can no longer live without. This seems to be a workplace policy issue, not a technical concern. You can have these extensions preconfigured in a central place as part of your Mercurial installation if that's desirable. [1] http://mercurial.selenic.com/wiki/Revlog http://mercurial.selenic.com/wiki/Revlog (note that the specific format did change in v0.9, but the principles remain the same). [2] http://marc.info/?l=git&m=116991865311836 http://marc.info/?l=git&m=116991865311836 [3] https://news.ycombinator.com/item?id=3548824 https://news.ycombinator.com/item?id=3548824 [4] Yes, I know that Bzr is not really being maintained actively by Canonical anymore, which is a shame, because in many respects, its design is far superior to either Git or Mercurial. Still, it's one of the reasons why quite a few people stick to it despite the lack of maintenance, because it bridges the gap between a fully distributed and a fully centralized VCS. [5] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
philsnow 12y ago
It might be better to wonder what are the advantages of mercurial over git. Better Windows support ? I think a huge proportion of OSS devs these days use linux / osx. It might be useful for mercurial to focus on making itself the premier OSS DVCS for "enterprise"; that would create space between it and git / the git userbase, and would allow for it to specialize in a meaningful way that is perhaps less-easily forklifted into git.
- maccard 12y ago
  > I think a huge proportion of OSS devs these days use linux / osx. For web development, maybe, but a huge amount of C++ development(games in particular) are almost exclusively done on windows
- mrbrowning 12y ago
  I'm a git user, but the one killer feature that Mercurial has that I'd love to see appear in Git some day is revsets [1]. It's a DSL for selecting commits from the repo's history that match a predicate, and you can easily create complex predicates with it that would be much more difficult or impossible to specify with git's brittle command line options. [1] http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets
  - philsnow 12y ago
    Those look very, very useful. Thanks for the pointer.
- schacon 12y ago
  While I'm generally uninterested in "git vs hg" these days, I am interested in this Windows question. Though I don't use Windows, I'm of the impression that Git is as solid on Windows today as Hg (or any other command line based tool) is. If you install GitHub for Windows, we will also install the command line version with good defaults automatically. It's fast and easy and works well. Is there any way you're aware of that Git for Windows is not as solid as Git on Linux or Mac?
Crito 12y ago
Git is simpler. If you understand the (very trivial) data model, then you understand what actions are possible, which actions are simple/complex or heavy/cheap, how to compose solutions for more complicated usecases, and how to reason yourself out of complex situations.
- jsmeaton 12y ago
  I used mercurial for a couple of years before switching to git precisely because mercurial was touted as the simpler choice. I believe I 'outgrew' mercurial, but I probably didn't invest time into discovering the various extensions and more complex components. That said, in no way is git simpler if you view "simple" as the time between knowing nothing and being able to push your commits.
  - Crito 12y ago
    User friendliness and simplicity are completely orthogonal. For instance, Microsoft Word is very user friendly, yet it is an immensely complex piece of software. I value simplicity over user friendliness. Despite git having several usability blemishes, it is insanely simple. The only simpler system that I have ever used is quilt (used to manage patch files). When mercurial advocates talk about simplicity, what they are actually talking about is superficial user friendliness.

I still wonder what are the advantages of git over mercurial.

by jokoon 12y ago

I still wonder what are the advantages of git over mercurial.

Perhaps the main advantage is that Git has won the mindshare war vs. Mercurial, and there are benefits to using what everyone else is using. Indeed, über-hacker Eric Raymond mentioned as recently as yesterday that he supports git even though he wishes hg had won instead. [1] [1]: http://esr.ibiblio.org/?p=6476 http://esr.ibiblio.org/?p=6476

Peaker 12y ago

Out of the box support for rebase and interactive rebase. Interactive commands to stage/unstage/commit. Better underlying data format: Checking out any version in history is a cheap operation. And generally better acceptance of the tool/wider familiarity.

rbehrends 12y ago
> Out of the box support for rebase and interactive rebase. Interactive commands to stage/unstage/commit. Mercurials has those features, too, if you desire them (whether they're a good thing to have is a different argument). These features are not enabled by default because they can either lose history (rebase) or are complicated for new users (or are of dubious benefit). You're probably confused by the fact that they're called extensions. I've always argued that the term "extensions" is misleading in this case. In actual fact, the bundled extensions are modules of the core system, which are maintained and supported at the same level as "core" Mercurial. See, e.g., this discussion: http://www.selenic.com/pipermail/mercurial/2013-November/046315.html http://www.selenic.com/pipermail/mercurial/2013-November/046... > Better underlying data format: Checking out any version in history is a cheap operation. Git actually has some serious scalability problems in places and no good way to overcome them, since the storage format is hardcoded. For example: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02015.html https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg02... I can't think of any version control system where checking out any version in history isn't fundamentally a cheap operation, either. This is not a Git-specific thing.
- Peaker 12y ago
  > are not enabled by default because they can either lose history (rebase) or are complicated for new users (or are of dubious benefit). Yet for me and many users, this means we cannot go to any coworker's terminal and use those features, many of us can no longer live without. > Git actually has some serious scalability problems in places and no good way to overcome them How so? You can upgrade the format in new versions (perhaps some abstractions to make it easy are missing, but there's enough development effort behind git that it doesn't have to be easy). I don't think hg is more scalable than git. > I can't think of any version control system where checking out any version in history isn't fundamentally a cheap operation, either. This is not a Git-specific thing. I read that hg uses some sort of a linear-append history format, meaning that going back to past versions is O(distance) in time. Is that false?
  - rbehrends 12y ago
    > I read that hg uses some sort of a linear-append history format, meaning that going back to past versions is O(distance) in time. Is that false? This is pretty much completely false. Mercurial stores repository data (except for the parts that relate to the current working tree) in revlog format [1], which is specifically designed to allow retrieval of arbitary revisions in time proportional to the file size (modulo what seek times spinning platter disks may impose for uncached sectors). The revlog format is designed to be append-only, but that actually is done to keep things fast by enabling random access based on an index; it does not lead to O(history size) operations. > I don't think hg is more scalable than git. Git actually has made a number of conscious design decisions that limit its scalability that other versions haven't made. To understand that this is largely intentional and not likely to go away in any meaningful way anytime soon, consider this post [2] by Linus Torvalds on the Git mailing list in 2007 regarding the "git blame" problem. There is a surprising willingness there to sacrifice usability and scalability on the altar of Git's super-simple repository format. Git's storage format is essentially a very simple transactional key-value store. While that has the benefit of allowing for a simple and robust implementation, it also makes certain operations more expensive than they need be (such as "git blame"). Some things Git can't even do, because it lacks the necessary metadata (such as avoiding spurious conflicts from first cherry-picking from a branch and later merging with the same branch). Others inherently require O(history length) or O(repository size) operations. Git was designed by people who considered a repository with a couple of hundred MB a big project; Git really starts breaking down once you hit the 1GB barrier. Checkout the gcc repository (about 1.4GB), for example, then do "git gc", and take a coffee break, because it'll take a couple of minutes. Somewhat famously, Facebook documented [3] some of their troubles with making Git scale. Git, unlike Bzr or Mercurial, does not have a pluggable storage layer that can be used to easily ameliorate these shortcomings. Bzr [4], as an extreme, can cheerfully operate on a remote repository in the exact same way as a local one, because it treats local file storage vs. ssh vs. http(s) vs. sftp etc. just as different implementations of the storage layer. Facebook extended Mercurial [5] to accomplish largely the same goal. Note that the above does not mean "Git sucks". For the most part, Git is a fine version control system, but where scalability is concerned, I'd pick a number of other VCSs first (and which is, frankly, why a lot of shops still use SVN over either Git or Mercurial; SVN may be more cumbersome to use, but it is a known quantity when it comes to handling large repositories). Git in particular is too much written like the typical C program, with a lot of concern for keeping constants low, but often with little concern for asymptotic worst-case complexity or extensibility. > Yet for me and many users, this means we cannot go to any coworker's terminal and use those features, many of us can no longer live without. This seems to be a workplace policy issue, not a technical concern. You can have these extensions preconfigured in a central place as part of your Mercurial installation if that's desirable. [1] http://mercurial.selenic.com/wiki/Revlog http://mercurial.selenic.com/wiki/Revlog (note that the specific format did change in v0.9, but the principles remain the same). [2] http://marc.info/?l=git&m=116991865311836 http://marc.info/?l=git&m=116991865311836 [3] https://news.ycombinator.com/item?id=3548824 https://news.ycombinator.com/item?id=3548824 [4] Yes, I know that Bzr is not really being maintained actively by Canonical anymore, which is a shame, because in many respects, its design is far superior to either Git or Mercurial. Still, it's one of the reasons why quite a few people stick to it despite the lack of maintenance, because it bridges the gap between a fully distributed and a fully centralized VCS. [5] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

philsnow 12y ago

It might be better to wonder what are the advantages of mercurial over git. Better Windows support ? I think a huge proportion of OSS devs these days use linux / osx. It might be useful for mercurial to focus on making itself the premier OSS DVCS for "enterprise"; that would create space between it and git / the git userbase, and would allow for it to specialize in a meaningful way that is perhaps less-easily forklifted into git.

maccard 12y ago
> I think a huge proportion of OSS devs these days use linux / osx. For web development, maybe, but a huge amount of C++ development(games in particular) are almost exclusively done on windows
mrbrowning 12y ago
I'm a git user, but the one killer feature that Mercurial has that I'd love to see appear in Git some day is revsets [1]. It's a DSL for selecting commits from the repo's history that match a predicate, and you can easily create complex predicates with it that would be much more difficult or impossible to specify with git's brittle command line options. [1] http://www.selenic.com/hg/help/revsets http://www.selenic.com/hg/help/revsets
- philsnow 12y ago
  Those look very, very useful. Thanks for the pointer.
schacon 12y ago
While I'm generally uninterested in "git vs hg" these days, I am interested in this Windows question. Though I don't use Windows, I'm of the impression that Git is as solid on Windows today as Hg (or any other command line based tool) is. If you install GitHub for Windows, we will also install the command line version with good defaults automatically. It's fast and easy and works well. Is there any way you're aware of that Git for Windows is not as solid as Git on Linux or Mac?

Crito 12y ago

Git is simpler. If you understand the (very trivial) data model, then you understand what actions are possible, which actions are simple/complex or heavy/cheap, how to compose solutions for more complicated usecases, and how to reason yourself out of complex situations.

jsmeaton 12y ago
I used mercurial for a couple of years before switching to git precisely because mercurial was touted as the simpler choice. I believe I 'outgrew' mercurial, but I probably didn't invest time into discovering the various extensions and more complex components. That said, in no way is git simpler if you view "simple" as the time between knowing nothing and being able to push your commits.
- Crito 12y ago
  User friendliness and simplicity are completely orthogonal. For instance, Microsoft Word is very user friendly, yet it is an immensely complex piece of software. I value simplicity over user friendliness. Despite git having several usability blemishes, it is insanely simple. The only simpler system that I have ever used is quilt (used to manage patch files). When mercurial advocates talk about simplicity, what they are actually talking about is superficial user friendliness.