7 ms·

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 does

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...
- stormbrew 12y ago
  > Git has 'user' branches, where a branch corresponds to the work of a user. Er. Not really, no. Git is simply agnostic about how you use branches, and allows you to separate how published branches and your local branches are used implicitly. I've rarely worked on a multi-user git project where published branches corresponded to a user's work. Almost always they are feature branches worked on alone or with someone else. Even in linux development, where the repositories are directly tied to users usually, the actual branches generally represent a work-unit of some sort, so I'm not sure where you got this idea.
  - acveilleux 12y ago
    It's probably pervasive because of github and pull requests where, at least for open-source projects and external contributors, it's true in practice though not enforced.
    - stormbrew 12y ago
      I'm confused as to what "it" means here? If you mean the idea in the GGP's post that branches represent a user's work, again I think that conflates repositories with branches. It's not exactly impossible to find people doing work on master of their fork against an OSS project, but best practices (and common practice among most regular contributors I've seen) seem to angle towards using feature branches even then (and asking with a PR to merge eg. stormbrew/blah:fix-the-thing to upstream/blah:master).
rbehrends 12y ago
> 1. Local branches Local branches are really an artifact of Git having a garbage collector. That means that any commit that you want to keep must be attached to a branch so that it may not be inadvertently lost. Without a garbage collector, that is not necessary. In particular, in many other VCSs, you just simply commit without having to create a branch in the first place. Labeling them (via whichever mechanisms your VCS provides) is typically optional with modern version control systems. You can argue that you prefer having a garbage collector over having to explicitly delete commits/branches that you do not want any longer, but that would be a different issue. > 2. Mercurial, without extensions, doesn't have the git shelf. This is sort of incorrect -- or rather, probably a misunderstanding. Shelve is part of standard Mercurial and has been for a while (same goes for MQ). While it is disabled by default and enabled in the extensions section, it's no more an extension in any meaningful sense of the word than git stash (which technically calls out to a shell script [1]). Mercurial's shelf is a python module [2] that is loaded when you flip a switch. > Both these points make hg easier to learn (branch == clone is very easy to wrap your head around, commit behaves basically like svn/cvs). This is really more a feature of Bazaar, not Mercurial. [1] https://github.com/git/git/blob/master/git-stash.sh https://github.com/git/git/blob/master/git-stash.sh [2] http://selenic.com/repo/hg-stable/file/default/hgext/shelve.py http://selenic.com/repo/hg-stable/file/default/hgext/shelve....
- saraid216 12y ago
  > In particular, in many other VCSs, you just simply commit without having to create a branch in the first place. Labeling them (via whichever mechanisms your VCS provides) is typically optional with modern version control systems. Since, for me, local branches are a massive part of why I prefer git, I'd be interested in examples of how to do the same thing in other VCSs. It doesn't make sense to me that they're a byproduct of having a garbage collector, since (1) git-stash exists, (2) local branches are a common selling point, and (3) git-clean honestly seems tacked on rather than a core piece of the design.
  - Blackthorn 12y ago
    For Mercurial, you create a new local branch by committing at a point that's not a tip (or not HEAD, if there's just a single branch). By default, it doesn't have a special name (like a git branch does). You can give it a name via "hg bookmark". The feature set is honestly fairly similar, it's just different in the way it is presented. In git you go into a "detached HEAD" and have to explicitly name a branch or commits will get lost. In hg you commit and it creates a new tip, but it doesn't have a name unless you explicitly name it via bookmark.

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...

stormbrew 12y ago
> Git has 'user' branches, where a branch corresponds to the work of a user. Er. Not really, no. Git is simply agnostic about how you use branches, and allows you to separate how published branches and your local branches are used implicitly. I've rarely worked on a multi-user git project where published branches corresponded to a user's work. Almost always they are feature branches worked on alone or with someone else. Even in linux development, where the repositories are directly tied to users usually, the actual branches generally represent a work-unit of some sort, so I'm not sure where you got this idea.
- acveilleux 12y ago
  It's probably pervasive because of github and pull requests where, at least for open-source projects and external contributors, it's true in practice though not enforced.
  - stormbrew 12y ago
    I'm confused as to what "it" means here? If you mean the idea in the GGP's post that branches represent a user's work, again I think that conflates repositories with branches. It's not exactly impossible to find people doing work on master of their fork against an OSS project, but best practices (and common practice among most regular contributors I've seen) seem to angle towards using feature branches even then (and asking with a PR to merge eg. stormbrew/blah:fix-the-thing to upstream/blah:master).

rbehrends 12y ago

> 1. Local branches Local branches are really an artifact of Git having a garbage collector. That means that any commit that you want to keep must be attached to a branch so that it may not be inadvertently lost. Without a garbage collector, that is not necessary. In particular, in many other VCSs, you just simply commit without having to create a branch in the first place. Labeling them (via whichever mechanisms your VCS provides) is typically optional with modern version control systems. You can argue that you prefer having a garbage collector over having to explicitly delete commits/branches that you do not want any longer, but that would be a different issue. > 2. Mercurial, without extensions, doesn't have the git shelf. This is sort of incorrect -- or rather, probably a misunderstanding. Shelve is part of standard Mercurial and has been for a while (same goes for MQ). While it is disabled by default and enabled in the extensions section, it's no more an extension in any meaningful sense of the word than git stash (which technically calls out to a shell script [1]). Mercurial's shelf is a python module [2] that is loaded when you flip a switch. > Both these points make hg easier to learn (branch == clone is very easy to wrap your head around, commit behaves basically like svn/cvs). This is really more a feature of Bazaar, not Mercurial. [1] https://github.com/git/git/blob/master/git-stash.sh https://github.com/git/git/blob/master/git-stash.sh [2] http://selenic.com/repo/hg-stable/file/default/hgext/shelve.py http://selenic.com/repo/hg-stable/file/default/hgext/shelve....

saraid216 12y ago
> In particular, in many other VCSs, you just simply commit without having to create a branch in the first place. Labeling them (via whichever mechanisms your VCS provides) is typically optional with modern version control systems. Since, for me, local branches are a massive part of why I prefer git, I'd be interested in examples of how to do the same thing in other VCSs. It doesn't make sense to me that they're a byproduct of having a garbage collector, since (1) git-stash exists, (2) local branches are a common selling point, and (3) git-clean honestly seems tacked on rather than a core piece of the design.
- Blackthorn 12y ago
  For Mercurial, you create a new local branch by committing at a point that's not a tip (or not HEAD, if there's just a single branch). By default, it doesn't have a special name (like a git branch does). You can give it a name via "hg bookmark". The feature set is honestly fairly similar, it's just different in the way it is presented. In git you go into a "detached HEAD" and have to explicitly name a branch or commits will get lost. In hg you commit and it creates a new tip, but it doesn't have a name unless you explicitly name it via bookmark.