11 ms·

Mercurial 2.8 Released

105 points by japaget 13y ago

elisee 13y ago
Release notes for the companion GUI TortoiseHg 2.10 release: https://bitbucket.org/tortoisehg/thg/wiki/ReleaseNotes#!tortoisehg-210 https://bitbucket.org/tortoisehg/thg/wiki/ReleaseNotes#!tort...
ohwp 13y ago
I think it's strange that Git seems more popular. Mercurial is a great tool. Also check TortoiseHg. Edit: I didn't want to start a flamewar. I'm just wondering why Git seems more popular because I think both tools are very good.
- mitchty 13y ago
  Github + Linux kernel I think would be the primary drivers for that. Mercurial is fine, but its hard to ignore inertia. Similar to FreeBSD/Linux.
  - EnderMB 13y ago
    Absolutely, in the same way that some companies went for Mercurial simply because BitBucket (at the time) offered free private repositories and only supported Hg. Now, BitBucket support Git repos, and I've noticed a few companies I've worked at that are starting to move towards Git on BitBucket, probably because it's the more popular choice and more people will know it because of GitHub. I use both Hg and Git at work, and to be honest for my basic workflow there are very few noticeable differences in day-to-day work.
    - jff 13y ago
      I use git on bitbucket for all my personal stuff, because by signing up with a .edu email account, they gave me free unlimited private repositories. Sold. My only concern would be that people are finding my mostly-bare github profile instead, since that rules the hivemind.
      - EnderMB 13y ago
        Ha, you're not alone there! Hell, the only reason I have projects on my GitHub profile are because I felt scared about having a bare public profile linked to my real name. Mine still looks a bit stupid, because I'm a .NET dev with three Java projects from uni, and a Python blog written for Google App Engine.
  - garenp 13y ago
    Totally agree with the first point in particular. The only reason I started using git is because it's required for github. Otherwise I'd use Mercurial exclusively.
- bluedino 13y ago
  Git has Linus, Linux, and Github behind it.
  - hugi 13y ago
    Github was the only reason I switched to Git from Mercurial.
  - tootie 13y ago
    Linus doesn't work on git anymore and I don't see what Linux has to do with anything. GitHub is to me the main reason for the success of git which I've discovered is incredibly difficult to use without GitHub. BitBucket good for me.
    - taspeotis 13y ago
      > Linus doesn't work on git anymore and I don't see what Linux has to do with anything Linus works with git because Linux kernel development uses git. You have, by default, thousands of pretty savvy developers working with git.
- taeric 13y ago
  The implication appears to be that Mercurial is better. Is it?
  - StavrosK 13y ago
    I find Mercurial's porcelain more intuitive than git's, yes.
    - rrrene 13y ago
      Could you elaborate on this? Do you mean CLI/UI?
      - StavrosK 13y ago
        Yes, I haven't used Mercurial too extensively (I use git), but Mercurial's commands make more sense to me. The only problem I have with it is that conflicts throw me into vim, and if I exit it to try and make sense of the merges, it thinks I'm done merging and leaves me in an unreasonable state, whereas git just marks the files and lets me resolve them at my leisure.
        durin42 13y ago
        You probably need to disable a merge tool. Check 'hg showconfig merge-tools' and you'll probably find something. If this is on a debian derived system, I think that package maintainer turns on a bunch of stuff by default, so you may need to find a file in /etc/hg or similar.
        hrydgard 13y ago
        Not that I use hg anymore, but if I remember correctly, exiting vim with :cq (returning an error code) solves that.
        StavrosK 13y ago
        That's very interesting to know in general, thank you.
- Silhouette 13y ago
  Mercurial is great at many things, but surprisingly, it seems quite awkward to set up a shared repository on your network for multiple users. It doesn't come as standard with a simple, self-contained server, and they recommend against using a shared directory on a network drive directly, presumably because of the wicked data loss bugs they've had (or may still have, I haven't checked this recently). Compare the Mercurial guidance on publishing repositories[1], which comes in at about 15 screens on my system, with the equivalents for say Git[2] or Bzr[3] that fit in a couple of screens, and you can see how striking the difference is. [1] http://mercurial.selenic.com/wiki/PublishingRepositories http://mercurial.selenic.com/wiki/PublishingRepositories [2] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-... [3] http://doc.bazaar.canonical.com/bzr-0.11/server.htm http://doc.bazaar.canonical.com/bzr-0.11/server.htm [Edit: Rephrase to avoid sounding unintentionally trollish. I'm trying to answer the question, not start a flame war.]
  - durin42 13y ago
    The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Note that on the Mercurial wiki page you linked, it does mention ssh setup, although perhaps not as prominently as you'd like. Also, hg /does/ come with a simple, self-contained server: hg serve. It doesn't support authentication, because there's a bunch of http servers that can do that for you better and with less bugs than we'd inevitably have.
    - Silhouette 13y ago
      The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Except that if you're running Windows rather than Linux, they don't. I have literally just tested it to make sure I'm not imagining things. The difference is that with Git you probably also have Git Bash installed on Windows, which while somewhat clunky does at least provide a fairly standardised mechanism for setting up keys etc. To my knowledge, there is no equivalent for Hg, and attempting to use hg with an ssh:// path to the repository seems to depend on what other software you have installed (Tortoise*, for example). If you know better, my team and I would love to learn something. This has been bugging us for years and across multiple projects, and none of us has ever found a simple, effective way of doing it. For the record, the mention of SSH setup on the page I linked to is literally just that: a mention, with no further details at all, and as noted above the obvious change of specifying an ssh:// path to a repository instead of a local one doesn't work by default on Windows. There's also a second entry for "Shared SSH", but that goes to a separate page describing half a dozen components that mostly aren't included with hg out of the box and again seem to lack much documentation in some cases. [Edit: Yes, there is also hg serve, but as you point out it lacks even basic security checks, and even the main Mercurial web site doesn't recommend relying on hg serve for more than temporary purposes.] [Edit 2: Rephrase to clarify shared SSH details.]
- japaget 13y ago
  The lack of any way to preserve file timestamps has made git a total non-starter for me. Mercurial has the TimestampMod extension (http://mercurial.selenic.com/wiki/TimestampModExtension http://mercurial.selenic.com/wiki/TimestampModExtension).
  - bitwalker 13y ago
    I'm curious why you need to preserve the timestamps. I'm not saying it doesn't make sense, I just haven't ever had a time where that's been a requirement.
  - saidajigumi 13y ago
    I'm really curious about your use-case. Are you just looking to tweak the behavior of the VCS w.r.t. a timestamp-sensitive build system? I will say that file timestamps invoke horrible, horrible memories of an employer that used Visual Source[un-]Safe -- a VCS that relied on accurate client system time for history integrity. I.e. the repo was easily corrupted if a client wasn't on synchronized time. Also, race conditions. AFAICT, it met none of the conditions casually denoted by the words "Version Control System".
  - jlgreco 13y ago
    It should probably be pretty trivial to roll together a TimestampMod equivalent using a similar methodology as git-notes. Hell, just store a git-note for every commit in a non-standard ref; each note would have a printout of the tree and corresponding timestamps. To reapply timestamps, you'd just have touch run through the git note, re-touching every file to have the appropriate timestamps. Like others have said though, I don't understand what a use case for this would be. The page for that Hg plugin seems to indicate that it is just meant to ease the transition to version control, for users who don't yet 'get it'.
- conductor 13y ago
  There is another very underrated DVCS called Fossil (open source, C) - http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
- poweribo 13y ago
  As a very good alternative to TortoiseHg, I find Atlassian's SourceTree to have better UI experience. sourcetreeapp.com
- rbanffy 13y ago
  > Also check TortoiseHg. One company I worked for chose Hg instead of Git precisely because it had better Windows support. One year and one acquisition later, every developer was on either Linux or OSX and everyone was asking why did we go for Hg if Windows was not a concern...
mariocesar 13y ago
Right now if you try to install it using pip `pip install Mercurial` will still install 2.7.2 version. Do instead: `pip install http://mercurial.selenic.com/release/mercurial-2.8.tar.gz` http://mercurial.selenic.com/release/mercurial-2.8.tar.gz`
- StavrosK 13y ago
  Yeah, looks like it hasn't been uploaded to the PyPI yet.
- durin42 13y ago
  Sorry about that, I've fixed that.
toggle 13y ago
I'm glad that the shelve extension (which is like stash in git) is included by default now. Even though that extension has been around for a while, it feels like it's considered a core function now, rather than an "extra." (Especially for git users, who are accustomed to having `git stash` out of the box. So now there's a little less friction when trying to do the same things in Mercurial.)
- twic 13y ago
  Yes, it is nice to have shelve in the core. That said, with Git, my main use of stash is to put away uncommitted changes so i can pull updates from the origin. Stash, pull, pop. However, Mercurial is able to pull changes into a working copy which has uncommitted changes - it essentially just treats it as a merge. This, with Mercurial, i need to stash much less often. It's still useful as a way of putting changes aside while you work on something else, though, so i am glad to have it. The alternative was doing things with patch queues which were a bit scary.
  - beagle3 13y ago
    Is mercurial's merging significantly different than git pull --rebase? (which acts like "cvs update" or "svn update" with respect to uncommitted changes?)
    - twic 13y ago
      Is git pull --rebase like cvs update with respect to uncommitted changes? If i issue a git pull --rebase (with Git 1.8.2.2) in a repo in which i have uncommitted changes, i get: Cannot pull with rebase: You have unstaged changes. Please commit or stash them. From what i remember of CVS, if i update into a working copy with changes, it applies the update where it can, and leaves merge conflict markers (or runs your configured merge tool) where it can't. That is also what Mercurial does.
      - beagle3 13y ago
        Ok, now I understand. Yes, git expects you to commit or stash before doing that, matching the philosophy that there should be a commit you can go back to undo (even if you have to look at the reflog to see what that commit is). Personally, I commit and stash all the time, and feel better than the old CVS in which I manually stashed (by copying) the pre-"cvs update" state in case I needed to go back to it. matsushiko above mentions that git now has --autostash; legit had "sync" which does stash-rebase-unstash - but I rarely ever needed that workflow.
deleted 13y ago
[deleted]
somnium_sn 13y ago
I like that Mercurial still tries hard to get new concepts into the core. There is something they call "phases" which is a boundary marking what was published and what not. Phases then forbid people to rebase changsets that were already published (unless you obv tell it to force it anyway), which is more more convenient than git's way. In addition they work on something called obsolete markers which will also record how changsets moved on rebase, etc giving it much more flexibility and power than git.
SmileyKeith 13y ago
Whenever the Git vs Mercurial topic comes up I think this thread [1] about Facebook having massive slowdowns with their large codebase using Git is quite interesting. [1]: http://thread.gmane.org/gmane.comp.version-control.git/189776 http://thread.gmane.org/gmane.comp.version-control.git/18977...
- the_mitsuhiko 13y ago
  How is this related to mercurial?
  - ngoldbaum 13y ago
    Facebook uses mercurial internally.
    - the_mitsuhiko 13y ago
      Source? That linked article is from when facebook used subversion.
      - tonfa 13y ago
        I don't know what they use in production, but Matt (mercurial project leader) currently works for FB: http://mercurial.selenic.com/wiki/mpm http://mercurial.selenic.com/wiki/mpm FB hired quite a few mercurial hacker, they host Mercurial sprints and have a big attendance from FB devs (e.g. London sprint): http://mercurial.selenic.com/wiki/2.6sprint http://mercurial.selenic.com/wiki/2.6sprint
      - ezquerra 13y ago
        The definitely do. They migrated their repositories to mercurial a while ago. There are plenty of mentions of this fact on mercurial's development mailing list (mercurial-devel@selenic.com). Facebook is a big user and backer of mercurial. I attended the last mercurial sprint in Facebook's London office (which was great, BTW). Facebook will also host the next mercurial sprint in New York. They have recently hired Matt Mackall, mercurial's creator. Several other mercurial core developers also work for Facebook and are paid to work on improving mercurial as their main job. I believe at some point they considered both git and mercurial as their new VCS. They have some huge repositories (hundreds of thousands if not millions of commits) and a huge amount of people accessing those repositories. I think they found some scalability issues with git's performance with repos of that scale (http://comments.gmane.org/gmane.comp.version-control.git/189776 http://comments.gmane.org/gmane.comp.version-control.git/189...). Apparently it was easier for them to improve mercurial's performance, perhaps because mercurial is written in python with some performance sensitive parts written in C. Over the last year they have made a lot of progress and mercurial's performance on huge repositories is now even better than it used to be.
AlexMax 13y ago
Mercurial is a fantastic VCS system that helped me get 'into" DVCS, and for that I am thankful. Even in 2013, it feels like it has the superior windows interface in TortoiseHG and I loved how extensions for Mercurial were usually a lot more cross-platform than git since they were usually just written in Python. That said, once I got my head around the full ramifications of Git's lightweight branching, I still think it was the better choice over named branches and bookmarks. When learning Mercurial, SVN-minded me naturally gravitated towards branches for everything because of the name, and learning the distinction of when to use bookmarks and when to use branches wasn't exactly clear until I finally understood how Git's branches worked - and at that point the thought of enshrining branch names in the history forevermore suddenly turned from an obvious "why not?" to a "why?". Git's interface can always get better, but Mercurial will always have branches that live forever in history and are named "Branches". Still, in Bizarro-2013 where Git never existed or never got the boost from Github, I think Mercurial would have been just as serviceable, and I think that it's a great second option to present if you want to migrate to a DVCS but your teammates can't get their head around Git. Kudos to them on another release.
- jordigh 13y ago
  There is a good reason to have branch names tattooed on commits: it makes inspecting the history much easier. When you are looking back and history and want to know why you did something, unless you're meticulous about encoding this information in your commit message, it helps a lot to have it encoded in the commit's metadata instead. There are also hg tools that help leverage named branches, e.g. revsets. Just today I wanted to figure out exactly on what commit did we merge the gui branch of Octave into default. I ran the following: hg log -r "children(parents(branch(default) and merge()) and branch(gui))" This told me that the merge happened a year ago, and told me exactly what commit did it. This would not be possible if the history did not record the branch name. I like hg's way: bookmarks for lightweight changes, named branches for long-lived lines of development. Both have their place, and both are useful.
  - AlexMax 13y ago
    Just because Git branches are lightweight doesn't mean they MUST be lightweight and thrown away. In your use-case, the `gui` branch ref would point at the merge commit, so you could simply ask for it by name. Being an old branch, however, you could then move the branch into an 'attic' or a different namespace than the active branches so it doesn't come up every time you `git branch`. That sort of flexibility to move branches around when needed was what made me question Mercurial's approach to forever-branches in the first place.
pnathan 13y ago
I spent a few years developing tooling and processes around Mercurial, then moved to a new role some months ago where Git is used exclusively. I am afraid that I still prefer hg; while git is, as a rule of thumb, faster, hg takes better care of your data (Much harder to lose changesets) and presents a cleaner UI out of the gate.
- Skinney 13y ago
  Much harder to loose changesets? The reflog keeps changesets for up to 90 days (default, can be configured), if you don't notice that changesets are missing for 90 days, then chances are they don't matter :/
  - twic 13y ago
    I am utterly flummoxed by the idea of a version control system that autonomously discards versions at all, even if it keeps them in a mysterious trashcan for 90 days. Last week, some colleagues of mine 'lost' some commits because some other colleagues had misused a forced push. They could probably have got them out of the reflog, if someone had told them about the reflog in time; before i could, they recovered a diff from their console history. If they'd been using Mercurial, the situation just wouldn't have arisen; they would have had a branch with two heads, and they could have resolved that straightforwardly. The fact that is would possible to recover from this situation using a command that one never has any other need to even know about is no excuse for the fact that it is even possible.
    - taspeotis 13y ago
      > some other colleagues had misused a forced push Git has a learning curve. Atlassian Stash comes with a plugin that exposes a "Disable Force Push" toggle. I have that on for all the repositories it hosts. Nobody complains that force push doesn't work (~10 devs) because if you're doing force push you're probably doing something wrong.
      - twic 13y ago

105 points by japaget 13y ago

Release notes for the companion GUI TortoiseHg 2.10 release: https://bitbucket.org/tortoisehg/thg/wiki/ReleaseNotes#!tortoisehg-210 https://bitbucket.org/tortoisehg/thg/wiki/ReleaseNotes#!tort...

ohwp 13y ago

I think it's strange that Git seems more popular. Mercurial is a great tool. Also check TortoiseHg. Edit: I didn't want to start a flamewar. I'm just wondering why Git seems more popular because I think both tools are very good.

mitchty 13y ago
Github + Linux kernel I think would be the primary drivers for that. Mercurial is fine, but its hard to ignore inertia. Similar to FreeBSD/Linux.
- EnderMB 13y ago
  Absolutely, in the same way that some companies went for Mercurial simply because BitBucket (at the time) offered free private repositories and only supported Hg. Now, BitBucket support Git repos, and I've noticed a few companies I've worked at that are starting to move towards Git on BitBucket, probably because it's the more popular choice and more people will know it because of GitHub. I use both Hg and Git at work, and to be honest for my basic workflow there are very few noticeable differences in day-to-day work.
  - jff 13y ago
    I use git on bitbucket for all my personal stuff, because by signing up with a .edu email account, they gave me free unlimited private repositories. Sold. My only concern would be that people are finding my mostly-bare github profile instead, since that rules the hivemind.
    - EnderMB 13y ago
      Ha, you're not alone there! Hell, the only reason I have projects on my GitHub profile are because I felt scared about having a bare public profile linked to my real name. Mine still looks a bit stupid, because I'm a .NET dev with three Java projects from uni, and a Python blog written for Google App Engine.
- garenp 13y ago
  Totally agree with the first point in particular. The only reason I started using git is because it's required for github. Otherwise I'd use Mercurial exclusively.
bluedino 13y ago
Git has Linus, Linux, and Github behind it.
- hugi 13y ago
  Github was the only reason I switched to Git from Mercurial.
- tootie 13y ago
  Linus doesn't work on git anymore and I don't see what Linux has to do with anything. GitHub is to me the main reason for the success of git which I've discovered is incredibly difficult to use without GitHub. BitBucket good for me.
  - taspeotis 13y ago
    > Linus doesn't work on git anymore and I don't see what Linux has to do with anything Linus works with git because Linux kernel development uses git. You have, by default, thousands of pretty savvy developers working with git.
taeric 13y ago
The implication appears to be that Mercurial is better. Is it?
- StavrosK 13y ago
  I find Mercurial's porcelain more intuitive than git's, yes.
  - rrrene 13y ago
    Could you elaborate on this? Do you mean CLI/UI?
    - StavrosK 13y ago
      Yes, I haven't used Mercurial too extensively (I use git), but Mercurial's commands make more sense to me. The only problem I have with it is that conflicts throw me into vim, and if I exit it to try and make sense of the merges, it thinks I'm done merging and leaves me in an unreasonable state, whereas git just marks the files and lets me resolve them at my leisure.
      - durin42 13y ago
        You probably need to disable a merge tool. Check 'hg showconfig merge-tools' and you'll probably find something. If this is on a debian derived system, I think that package maintainer turns on a bunch of stuff by default, so you may need to find a file in /etc/hg or similar.
      - hrydgard 13y ago
        Not that I use hg anymore, but if I remember correctly, exiting vim with :cq (returning an error code) solves that.
        StavrosK 13y ago
        That's very interesting to know in general, thank you.
Silhouette 13y ago
Mercurial is great at many things, but surprisingly, it seems quite awkward to set up a shared repository on your network for multiple users. It doesn't come as standard with a simple, self-contained server, and they recommend against using a shared directory on a network drive directly, presumably because of the wicked data loss bugs they've had (or may still have, I haven't checked this recently). Compare the Mercurial guidance on publishing repositories[1], which comes in at about 15 screens on my system, with the equivalents for say Git[2] or Bzr[3] that fit in a couple of screens, and you can see how striking the difference is. [1] http://mercurial.selenic.com/wiki/PublishingRepositories http://mercurial.selenic.com/wiki/PublishingRepositories [2] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-... [3] http://doc.bazaar.canonical.com/bzr-0.11/server.htm http://doc.bazaar.canonical.com/bzr-0.11/server.htm [Edit: Rephrase to avoid sounding unintentionally trollish. I'm trying to answer the question, not start a flame war.]
- durin42 13y ago
  The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Note that on the Mercurial wiki page you linked, it does mention ssh setup, although perhaps not as prominently as you'd like. Also, hg /does/ come with a simple, self-contained server: hg serve. It doesn't support authentication, because there's a bunch of http servers that can do that for you better and with less bugs than we'd inevitably have.
  - Silhouette 13y ago
    The instructions you linked for git would basically work as stated for Mercurial, but without all the mucking about with making a bare repository. Except that if you're running Windows rather than Linux, they don't. I have literally just tested it to make sure I'm not imagining things. The difference is that with Git you probably also have Git Bash installed on Windows, which while somewhat clunky does at least provide a fairly standardised mechanism for setting up keys etc. To my knowledge, there is no equivalent for Hg, and attempting to use hg with an ssh:// path to the repository seems to depend on what other software you have installed (Tortoise*, for example). If you know better, my team and I would love to learn something. This has been bugging us for years and across multiple projects, and none of us has ever found a simple, effective way of doing it. For the record, the mention of SSH setup on the page I linked to is literally just that: a mention, with no further details at all, and as noted above the obvious change of specifying an ssh:// path to a repository instead of a local one doesn't work by default on Windows. There's also a second entry for "Shared SSH", but that goes to a separate page describing half a dozen components that mostly aren't included with hg out of the box and again seem to lack much documentation in some cases. [Edit: Yes, there is also hg serve, but as you point out it lacks even basic security checks, and even the main Mercurial web site doesn't recommend relying on hg serve for more than temporary purposes.] [Edit 2: Rephrase to clarify shared SSH details.]
japaget 13y ago
The lack of any way to preserve file timestamps has made git a total non-starter for me. Mercurial has the TimestampMod extension (http://mercurial.selenic.com/wiki/TimestampModExtension http://mercurial.selenic.com/wiki/TimestampModExtension).
- bitwalker 13y ago
  I'm curious why you need to preserve the timestamps. I'm not saying it doesn't make sense, I just haven't ever had a time where that's been a requirement.
- saidajigumi 13y ago
  I'm really curious about your use-case. Are you just looking to tweak the behavior of the VCS w.r.t. a timestamp-sensitive build system? I will say that file timestamps invoke horrible, horrible memories of an employer that used Visual Source[un-]Safe -- a VCS that relied on accurate client system time for history integrity. I.e. the repo was easily corrupted if a client wasn't on synchronized time. Also, race conditions. AFAICT, it met none of the conditions casually denoted by the words "Version Control System".
- jlgreco 13y ago
  It should probably be pretty trivial to roll together a TimestampMod equivalent using a similar methodology as git-notes. Hell, just store a git-note for every commit in a non-standard ref; each note would have a printout of the tree and corresponding timestamps. To reapply timestamps, you'd just have touch run through the git note, re-touching every file to have the appropriate timestamps. Like others have said though, I don't understand what a use case for this would be. The page for that Hg plugin seems to indicate that it is just meant to ease the transition to version control, for users who don't yet 'get it'.
conductor 13y ago
There is another very underrated DVCS called Fossil (open source, C) - http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
poweribo 13y ago
As a very good alternative to TortoiseHg, I find Atlassian's SourceTree to have better UI experience. sourcetreeapp.com
rbanffy 13y ago
> Also check TortoiseHg. One company I worked for chose Hg instead of Git precisely because it had better Windows support. One year and one acquisition later, every developer was on either Linux or OSX and everyone was asking why did we go for Hg if Windows was not a concern...

mariocesar 13y ago

Right now if you try to install it using pip `pip install Mercurial` will still install 2.7.2 version. Do instead: `pip install http://mercurial.selenic.com/release/mercurial-2.8.tar.gz` http://mercurial.selenic.com/release/mercurial-2.8.tar.gz`

StavrosK 13y ago
Yeah, looks like it hasn't been uploaded to the PyPI yet.
durin42 13y ago
Sorry about that, I've fixed that.

toggle 13y ago

I'm glad that the shelve extension (which is like stash in git) is included by default now. Even though that extension has been around for a while, it feels like it's considered a core function now, rather than an "extra." (Especially for git users, who are accustomed to having `git stash` out of the box. So now there's a little less friction when trying to do the same things in Mercurial.)

twic 13y ago
Yes, it is nice to have shelve in the core. That said, with Git, my main use of stash is to put away uncommitted changes so i can pull updates from the origin. Stash, pull, pop. However, Mercurial is able to pull changes into a working copy which has uncommitted changes - it essentially just treats it as a merge. This, with Mercurial, i need to stash much less often. It's still useful as a way of putting changes aside while you work on something else, though, so i am glad to have it. The alternative was doing things with patch queues which were a bit scary.
- beagle3 13y ago
  Is mercurial's merging significantly different than git pull --rebase? (which acts like "cvs update" or "svn update" with respect to uncommitted changes?)
  - twic 13y ago
    Is git pull --rebase like cvs update with respect to uncommitted changes? If i issue a git pull --rebase (with Git 1.8.2.2) in a repo in which i have uncommitted changes, i get: Cannot pull with rebase: You have unstaged changes. Please commit or stash them. From what i remember of CVS, if i update into a working copy with changes, it applies the update where it can, and leaves merge conflict markers (or runs your configured merge tool) where it can't. That is also what Mercurial does.
    - beagle3 13y ago
      Ok, now I understand. Yes, git expects you to commit or stash before doing that, matching the philosophy that there should be a commit you can go back to undo (even if you have to look at the reflog to see what that commit is). Personally, I commit and stash all the time, and feel better than the old CVS in which I manually stashed (by copying) the pre-"cvs update" state in case I needed to go back to it. matsushiko above mentions that git now has --autostash; legit had "sync" which does stash-rebase-unstash - but I rarely ever needed that workflow.

deleted 13y ago

[deleted]

somnium_sn 13y ago

I like that Mercurial still tries hard to get new concepts into the core. There is something they call "phases" which is a boundary marking what was published and what not. Phases then forbid people to rebase changsets that were already published (unless you obv tell it to force it anyway), which is more more convenient than git's way. In addition they work on something called obsolete markers which will also record how changsets moved on rebase, etc giving it much more flexibility and power than git.

SmileyKeith 13y ago

Whenever the Git vs Mercurial topic comes up I think this thread [1] about Facebook having massive slowdowns with their large codebase using Git is quite interesting. [1]: http://thread.gmane.org/gmane.comp.version-control.git/189776 http://thread.gmane.org/gmane.comp.version-control.git/18977...

the_mitsuhiko 13y ago
How is this related to mercurial?
- ngoldbaum 13y ago
  Facebook uses mercurial internally.
  - the_mitsuhiko 13y ago
    Source? That linked article is from when facebook used subversion.
    - tonfa 13y ago
      I don't know what they use in production, but Matt (mercurial project leader) currently works for FB: http://mercurial.selenic.com/wiki/mpm http://mercurial.selenic.com/wiki/mpm FB hired quite a few mercurial hacker, they host Mercurial sprints and have a big attendance from FB devs (e.g. London sprint): http://mercurial.selenic.com/wiki/2.6sprint http://mercurial.selenic.com/wiki/2.6sprint
    - ezquerra 13y ago
      The definitely do. They migrated their repositories to mercurial a while ago. There are plenty of mentions of this fact on mercurial's development mailing list (mercurial-devel@selenic.com). Facebook is a big user and backer of mercurial. I attended the last mercurial sprint in Facebook's London office (which was great, BTW). Facebook will also host the next mercurial sprint in New York. They have recently hired Matt Mackall, mercurial's creator. Several other mercurial core developers also work for Facebook and are paid to work on improving mercurial as their main job. I believe at some point they considered both git and mercurial as their new VCS. They have some huge repositories (hundreds of thousands if not millions of commits) and a huge amount of people accessing those repositories. I think they found some scalability issues with git's performance with repos of that scale (http://comments.gmane.org/gmane.comp.version-control.git/189776 http://comments.gmane.org/gmane.comp.version-control.git/189...). Apparently it was easier for them to improve mercurial's performance, perhaps because mercurial is written in python with some performance sensitive parts written in C. Over the last year they have made a lot of progress and mercurial's performance on huge repositories is now even better than it used to be.

AlexMax 13y ago

Mercurial is a fantastic VCS system that helped me get 'into" DVCS, and for that I am thankful. Even in 2013, it feels like it has the superior windows interface in TortoiseHG and I loved how extensions for Mercurial were usually a lot more cross-platform than git since they were usually just written in Python. That said, once I got my head around the full ramifications of Git's lightweight branching, I still think it was the better choice over named branches and bookmarks. When learning Mercurial, SVN-minded me naturally gravitated towards branches for everything because of the name, and learning the distinction of when to use bookmarks and when to use branches wasn't exactly clear until I finally understood how Git's branches worked - and at that point the thought of enshrining branch names in the history forevermore suddenly turned from an obvious "why not?" to a "why?". Git's interface can always get better, but Mercurial will always have branches that live forever in history and are named "Branches". Still, in Bizarro-2013 where Git never existed or never got the boost from Github, I think Mercurial would have been just as serviceable, and I think that it's a great second option to present if you want to migrate to a DVCS but your teammates can't get their head around Git. Kudos to them on another release.

jordigh 13y ago
There is a good reason to have branch names tattooed on commits: it makes inspecting the history much easier. When you are looking back and history and want to know why you did something, unless you're meticulous about encoding this information in your commit message, it helps a lot to have it encoded in the commit's metadata instead. There are also hg tools that help leverage named branches, e.g. revsets. Just today I wanted to figure out exactly on what commit did we merge the gui branch of Octave into default. I ran the following: hg log -r "children(parents(branch(default) and merge()) and branch(gui))" This told me that the merge happened a year ago, and told me exactly what commit did it. This would not be possible if the history did not record the branch name. I like hg's way: bookmarks for lightweight changes, named branches for long-lived lines of development. Both have their place, and both are useful.
- AlexMax 13y ago
  Just because Git branches are lightweight doesn't mean they MUST be lightweight and thrown away. In your use-case, the `gui` branch ref would point at the merge commit, so you could simply ask for it by name. Being an old branch, however, you could then move the branch into an 'attic' or a different namespace than the active branches so it doesn't come up every time you `git branch`. That sort of flexibility to move branches around when needed was what made me question Mercurial's approach to forever-branches in the first place.

pnathan 13y ago

I spent a few years developing tooling and processes around Mercurial, then moved to a new role some months ago where Git is used exclusively. I am afraid that I still prefer hg; while git is, as a rule of thumb, faster, hg takes better care of your data (Much harder to lose changesets) and presents a cleaner UI out of the gate.

Skinney 13y ago
Much harder to loose changesets? The reflog keeps changesets for up to 90 days (default, can be configured), if you don't notice that changesets are missing for 90 days, then chances are they don't matter :/
- twic 13y ago
  I am utterly flummoxed by the idea of a version control system that autonomously discards versions at all, even if it keeps them in a mysterious trashcan for 90 days. Last week, some colleagues of mine 'lost' some commits because some other colleagues had misused a forced push. They could probably have got them out of the reflog, if someone had told them about the reflog in time; before i could, they recovered a diff from their console history. If they'd been using Mercurial, the situation just wouldn't have arisen; they would have had a branch with two heads, and they could have resolved that straightforwardly. The fact that is would possible to recover from this situation using a command that one never has any other need to even know about is no excuse for the fact that it is even possible.
  - taspeotis 13y ago
    > some other colleagues had misused a forced push Git has a learning curve. Atlassian Stash comes with a plugin that exposes a "Disable Force Push" toggle. I have that on for all the repositories it hosts. Nobody complains that force push doesn't work (~10 devs) because if you're doing force push you're probably doing something wrong.
    - twic 13y ago