9 ms·

Mercurial has seriously improved over the past couple of years. If you tried mercurial a few years ago and were scared away due to speed or functionality issue

Mercurial has seriously improved over the past couple of years. If you tried mercurial a few years ago and were scared away due to speed or functionality issues, you might want to give it another shot.

JoshTriplett 13y ago
Does the standard branch workflow still expect you to have a separate repository and directory per branch? I don't care about plugins, here; if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. Likewise, does the standard workflow still intentionally make it painful to rearrange changes in your local repository to construct a series of patches? Does Mercurial provide built-in commands equivalent to "commit --amend", "rebase -i", and "add -p"?
- ngoldbaum 13y ago
  Mercurial refers to git-like lightweight branches as bookmarks [1]. Branches are still permanent tags in the repository. Commit --amend is now part of base mercurial. Rebase is available as an extension that is shipped with the client, like most advanced functionality. I don't know what add -p does. [1] http://mercurial.selenic.com/wiki/Bookmarks/ http://mercurial.selenic.com/wiki/Bookmarks/
  - durin42 13y ago
    "add -p" is basically the 'hg record' extension.
    - _ikke_ 13y ago
      It's more like `git commit -p`. If you abort `hg record`, the selection you've made is lost.
- mikegioia 13y ago
  I work in several branches in the same file system directory. Branching in mercurial is as simple as "hg branch branchname", and switching branches is just "hg update branchname". As long as you make sure you commit everything you can easily work in one directory. Merging changes across branches is easy too, as you only need to specify the revision number.
  - ahomescu1 13y ago
    If you push while having open local branches, they get pushed to the remote (or at least that's how it was last time I used them). That's not what you want, in most cases (git branches are local).
    - rbehrends 13y ago
      Mercurial won't push new branches unless you specify -f or --new-branch. You can selectively push only the branches you want with hg push -r branch_or_revision (hg push -r . for the current revision). You can also hide branches using phases, so they won't be pushed even with -f or --new-branch.
      - ahomescu1 13y ago
        The guide from [1] confirms it works the way I saw it (it pushes all branches): Mercurial will push/pull all branches by default, while git will push/pull only the current branch. Did this behavior change in recent versions of hg? 1 - http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
        rbehrends 13y ago
        Mercurial will attempt to push all branches. It will then immediately stop with an error message unless you specify -f or --new-branch if you're trying to push a branch that does not already exist in the remote repository (or even to create a new head in an existing branch). In order to get rid of the error message you need to either (1) explicitly tell Mercurial to push all branches, (2) specify which existing branch(es)/revision(s) you want to push (they must already exist remotely), or (3) hide the branch with hg phase secret -f. This means that your local branches will not leak into the remote repository unless you specifically instruct Mercurial to do so. Of these, only the phase approach is new (2.1+). The rest hasn't changed.
- jordigh 13y ago
  > if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. There is no real standard workflow. There are tools in place to build whatever you want. This is old, but remarkably still relevant: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... If you want git-like branches, Mercurial bookmarks are close, but not quite the same. They have some intentional differences, which make sense and do not impede you, but will not make sense if you absolutely want them to behave like git branches. > "commit --amend", "rebase -i", and "add -p"? hg commit --amend, hg histedit, hg record (but hg crecord is much nicer). They're built-in, but you have to flip them on the last two with a config switch.
  - JoshTriplett 13y ago
    That post helped, and bookmarks might get the job done, but the mercurial culture doesn't seem to encourage them compared to branches. As a result, you tend to find a lot more separate mercurial repositories than single repos with bookmarks, and a lot more named branches with hard-to-eliminate commits as well (since even "closing" a branch doesn't really get rid of it). > hg commit --amend, hg histedit, hg record (but hg crecord is much nicer). > They're built-in, but you have to flip them on the last two with a config switch. And that's the fundamental attitude that I can't stand in mercurial's culture: "careful, you might accidentally throw away that information you specifically wanted to throw away". Those commands aren't available by default because the culture doesn't encourage that workflow, so even if you use them for your own personal workflow you'll tend to find a lot more junk commits and forever-remembered branch names in the average mercurial repository.
    - mixmastamyk 13y ago
      I might have read this wrong, but safety for newbies doesn't sound all that bad to me.
      - JoshTriplett 13y ago
        History editing in git is not unsafe: because it's a part of the default set of tools, git offers functionality like the reflog to keep track of old history locally and avoid losing it. It's extremely difficult to permanently lose content in a git repository even using the history editing commands; it's always just a "git reflog" away.
- durin42 13y ago
  Note that extensions that ship with Mercurial are exactly as supported as the tool itself, and come with the same kinds of backwards compatibility guarantees. It's not worth worrying about rebase, histedit, and record being extensions - if you want them, turn them on and use them.
  - JoshTriplett 13y ago
    They're not exactly as supported, because they're not on by default, and they're not the thing everyone in the Mercurial culture tells you to use as the obvious solution to problems. Version control is as much about what other people do as what you do, and what other people do tends to align most closely with the defaults and what the tools encourage.
    - durin42 13y ago
      No, they're exactly as supported. What I meant by that was that we promise to not break them, ever, to keep the output formats stable, and accept bug reports for them. That doesn't necessarily mean it's something we'll always recommend (eg mq isn't something I'd recommend for a new user, rebase/histedit/amend are way better and always will be.) We don't turn them on by default for two reasons: newbie users not shooting their foot off unexpectedly, and UI clutter. mq alone (which we actually recommend avoiding now if you don't really need it) adds a bunch of verbs to the command line interface. We've talked about having an 'hg hello' command or something that'd give you a proposed template hgrc that suggest you might want rebase/record/histedit/pager/color/progress, but nobody's worked out exactly what that should be like. Does something like that sound like it might be helpful?
      - mushishi 13y ago
        Could you elaborate on why to avoid mq?
        masklinn 13y ago
        It's a very powerful tool, but also a complex one, and one which brings in a bunch of new commands. There are a bunch of extension which provide nice UIs to various subsets of mq's full power, and are much simpler. If you need mq, use mq, but if you just need to e.g. do some history edition, use histedit.
- k_bx 13y ago
  Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?
  - wtetzner 13y ago
    I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit. It's conceptually lightweight.
    - JoshTriplett 13y ago
      Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.
      - k_bx 13y ago
        Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.
    - k_bx 13y ago
      Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?
  - fhd2 13y ago
    According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I can think of.
    - 13y ago
- Uchikoma 13y ago
  Let me translate: "if this tool is not exactly like Git, I will not use it".
  - gecko 13y ago
    That sentiment comprises a truly mindblowing number of "bug" reports that hit the Mercurial mailing list every month. I honestly wonder sometimes if I'm simply forgetting how CVS users did the same thing when Subversion shipped and I forgot about it/missed it, or what.
    - durin42 13y ago
      svn was designed to be "CVS done right," which informed a lot of the design and workflow to the point that some CVS misfeatures only got carried through by virtue of that mandate. (Source of this assertion is prolonged discussions with sussman, one of the early svn authors.)
  - JoshTriplett 13y ago
    Not exactly, but close. Switching away from Git would require a tool that is both compellingly better in some key way as well as not worse for any existing workflow. I have yet to see any other version control system that meets both of those criteria, even leaving aside the network effects of using the most popular system.
- masklinn 13y ago
  > Does the standard branch workflow still expect you to have a separate repository and directory per branch? You're probably confusing mercurial with bazaar, mercurial has always had branches (though they're not quite the same as git, mercurial's bookmarks are more closely related to git branches) and anonymous heads (contrary to git, an unnamed head is not stuck in limbo). > I don't care about plugins That's stupid, mercurial is very much about plugins: there are dozens of official plugins shipped in a standard mercurial install. > the standard workflow there is no such thing. > Does Mercurial provide built-in commands equivalent to "commit --amend", "rebase -i", and "add -p"? All of them are provided in the base install, you just have to enable the corresponding extensions.
  - ahomescu1 13y ago
    Mercurial's branches are server side (learned that the hard way the first time I made a branch), git's are client side.
    - tonfa 13y ago
      I think you are confused, git and hg branches are very similar (I'd try to help but I'm not sure what the confusion is).
      - ahomescu1 13y ago
        It's simple: I created a local branch, worked on it, then tried the git workflow: 1. Switch to the default branch 2. Cherry-pick (with the equivalent hg command) my changes from my own branch into default 3. Push the changes to the remote repo What happened was that my local branch got pushed to the server, along with the default one. With git this wouldn't happen, it would push the local master to the remote master.
        tonfa 13y ago
        Yes, by default all branches are pushed, (you would have to use --force if it creates new heads, and --new-branch to push new named branches). But I really don't see how it makes anything "server" or "client" side. (and you could in any case decide to push just default: hg push -r default)

JoshTriplett 13y ago

Does the standard branch workflow still expect you to have a separate repository and directory per branch? I don't care about plugins, here; if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. Likewise, does the standard workflow still intentionally make it painful to rearrange changes in your local repository to construct a series of patches? Does Mercurial provide built-in commands equivalent to "commit --amend", "rebase -i", and "add -p"?

ngoldbaum 13y ago
Mercurial refers to git-like lightweight branches as bookmarks [1]. Branches are still permanent tags in the repository. Commit --amend is now part of base mercurial. Rebase is available as an extension that is shipped with the client, like most advanced functionality. I don't know what add -p does. [1] http://mercurial.selenic.com/wiki/Bookmarks/ http://mercurial.selenic.com/wiki/Bookmarks/
- durin42 13y ago
  "add -p" is basically the 'hg record' extension.
  - _ikke_ 13y ago
    It's more like `git commit -p`. If you abort `hg record`, the selection you've made is lost.
mikegioia 13y ago
I work in several branches in the same file system directory. Branching in mercurial is as simple as "hg branch branchname", and switching branches is just "hg update branchname". As long as you make sure you commit everything you can easily work in one directory. Merging changes across branches is easy too, as you only need to specify the revision number.
- ahomescu1 13y ago
  If you push while having open local branches, they get pushed to the remote (or at least that's how it was last time I used them). That's not what you want, in most cases (git branches are local).
  - rbehrends 13y ago
    Mercurial won't push new branches unless you specify -f or --new-branch. You can selectively push only the branches you want with hg push -r branch_or_revision (hg push -r . for the current revision). You can also hide branches using phases, so they won't be pushed even with -f or --new-branch.
    - ahomescu1 13y ago
      The guide from [1] confirms it works the way I saw it (it pushes all branches): Mercurial will push/pull all branches by default, while git will push/pull only the current branch. Did this behavior change in recent versions of hg? 1 - http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
      - rbehrends 13y ago
        Mercurial will attempt to push all branches. It will then immediately stop with an error message unless you specify -f or --new-branch if you're trying to push a branch that does not already exist in the remote repository (or even to create a new head in an existing branch). In order to get rid of the error message you need to either (1) explicitly tell Mercurial to push all branches, (2) specify which existing branch(es)/revision(s) you want to push (they must already exist remotely), or (3) hide the branch with hg phase secret -f. This means that your local branches will not leak into the remote repository unless you specifically instruct Mercurial to do so. Of these, only the phase approach is new (2.1+). The rest hasn't changed.
jordigh 13y ago
> if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. There is no real standard workflow. There are tools in place to build whatever you want. This is old, but remarkably still relevant: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... If you want git-like branches, Mercurial bookmarks are close, but not quite the same. They have some intentional differences, which make sense and do not impede you, but will not make sense if you absolutely want them to behave like git branches. > "commit --amend", "rebase -i", and "add -p"? hg commit --amend, hg histedit, hg record (but hg crecord is much nicer). They're built-in, but you have to flip them on the last two with a config switch.
- JoshTriplett 13y ago
  That post helped, and bookmarks might get the job done, but the mercurial culture doesn't seem to encourage them compared to branches. As a result, you tend to find a lot more separate mercurial repositories than single repos with bookmarks, and a lot more named branches with hard-to-eliminate commits as well (since even "closing" a branch doesn't really get rid of it). > hg commit --amend, hg histedit, hg record (but hg crecord is much nicer). > They're built-in, but you have to flip them on the last two with a config switch. And that's the fundamental attitude that I can't stand in mercurial's culture: "careful, you might accidentally throw away that information you specifically wanted to throw away". Those commands aren't available by default because the culture doesn't encourage that workflow, so even if you use them for your own personal workflow you'll tend to find a lot more junk commits and forever-remembered branch names in the average mercurial repository.
  - mixmastamyk 13y ago
    I might have read this wrong, but safety for newbies doesn't sound all that bad to me.
    - JoshTriplett 13y ago
      History editing in git is not unsafe: because it's a part of the default set of tools, git offers functionality like the reflog to keep track of old history locally and avoid losing it. It's extremely difficult to permanently lose content in a git repository even using the history editing commands; it's always just a "git reflog" away.
durin42 13y ago
Note that extensions that ship with Mercurial are exactly as supported as the tool itself, and come with the same kinds of backwards compatibility guarantees. It's not worth worrying about rebase, histedit, and record being extensions - if you want them, turn them on and use them.
- JoshTriplett 13y ago
  They're not exactly as supported, because they're not on by default, and they're not the thing everyone in the Mercurial culture tells you to use as the obvious solution to problems. Version control is as much about what other people do as what you do, and what other people do tends to align most closely with the defaults and what the tools encourage.
  - durin42 13y ago
    No, they're exactly as supported. What I meant by that was that we promise to not break them, ever, to keep the output formats stable, and accept bug reports for them. That doesn't necessarily mean it's something we'll always recommend (eg mq isn't something I'd recommend for a new user, rebase/histedit/amend are way better and always will be.) We don't turn them on by default for two reasons: newbie users not shooting their foot off unexpectedly, and UI clutter. mq alone (which we actually recommend avoiding now if you don't really need it) adds a bunch of verbs to the command line interface. We've talked about having an 'hg hello' command or something that'd give you a proposed template hgrc that suggest you might want rebase/record/histedit/pager/color/progress, but nobody's worked out exactly what that should be like. Does something like that sound like it might be helpful?
    - mushishi 13y ago
      Could you elaborate on why to avoid mq?
      - masklinn 13y ago
        It's a very powerful tool, but also a complex one, and one which brings in a bunch of new commands. There are a bunch of extension which provide nice UIs to various subsets of mq's full power, and are much simpler. If you need mq, use mq, but if you just need to e.g. do some history edition, use histedit.
k_bx 13y ago
Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?
- wtetzner 13y ago
  I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit. It's conceptually lightweight.
  - JoshTriplett 13y ago
    Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.
    - k_bx 13y ago
      Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.
  - k_bx 13y ago
    Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?
- fhd2 13y ago
  According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I can think of.
  - 13y ago
Uchikoma 13y ago
Let me translate: "if this tool is not exactly like Git, I will not use it".
- gecko 13y ago
  That sentiment comprises a truly mindblowing number of "bug" reports that hit the Mercurial mailing list every month. I honestly wonder sometimes if I'm simply forgetting how CVS users did the same thing when Subversion shipped and I forgot about it/missed it, or what.
  - durin42 13y ago
    svn was designed to be "CVS done right," which informed a lot of the design and workflow to the point that some CVS misfeatures only got carried through by virtue of that mandate. (Source of this assertion is prolonged discussions with sussman, one of the early svn authors.)
- JoshTriplett 13y ago
  Not exactly, but close. Switching away from Git would require a tool that is both compellingly better in some key way as well as not worse for any existing workflow. I have yet to see any other version control system that meets both of those criteria, even leaving aside the network effects of using the most popular system.
masklinn 13y ago
> Does the standard branch workflow still expect you to have a separate repository and directory per branch? You're probably confusing mercurial with bazaar, mercurial has always had branches (though they're not quite the same as git, mercurial's bookmarks are more closely related to git branches) and anonymous heads (contrary to git, an unnamed head is not stuck in limbo). > I don't care about plugins That's stupid, mercurial is very much about plugins: there are dozens of official plugins shipped in a standard mercurial install. > the standard workflow there is no such thing. > Does Mercurial provide built-in commands equivalent to "commit --amend", "rebase -i", and "add -p"? All of them are provided in the base install, you just have to enable the corresponding extensions.
- ahomescu1 13y ago
  Mercurial's branches are server side (learned that the hard way the first time I made a branch), git's are client side.
  - tonfa 13y ago
    I think you are confused, git and hg branches are very similar (I'd try to help but I'm not sure what the confusion is).
    - ahomescu1 13y ago
      It's simple: I created a local branch, worked on it, then tried the git workflow: 1. Switch to the default branch 2. Cherry-pick (with the equivalent hg command) my changes from my own branch into default 3. Push the changes to the remote repo What happened was that my local branch got pushed to the server, along with the default one. With git this wouldn't happen, it would push the local master to the remote master.
      - tonfa 13y ago
        Yes, by default all branches are pushed, (you would have to use --force if it creates new heads, and --new-branch to push new named branches). But I really don't see how it makes anything "server" or "client" side. (and you could in any case decide to push just default: hg push -r default)