12 ms·

What's New in Mercurial 3.0

226 points by anton_gogolev 12y ago

VoiceOfWisdom 12y ago
I am so excited for Changset Evolution. The only thing I miss having from git in mercurial, is the ability to safely rewrite commit history.
- krallja 12y ago
  I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.
  - scott_karana 12y ago
    I agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere.
    - mpdehaan2 12y ago
      This is probably due to an understanding of rebases, rebases should be used to bring your commits to the top of the stack for easy review in OSS projects. Amazingly useful for making sure patches are easy to apply while following a remote branch. My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local branches more sane -- but it's frustrating because it's not the same thing.
      - Crito 12y ago
        Wait, "quilt" as in the tool that manages patch files? That's still in use? Or is quilt a new Hg extension?
        mpdehaan2 12y ago
        I think I meant queues. I was looking for the plugin and failing to find it, but it was basically a thing like quilt but an Hg extension. Was not a fan :)
      - jordigh 12y ago
        > and having to use things like quilt on top to try to make local branches more sane I consider Mercurial Queues as one of Mercurial's youthful mistakes. It was ok in 2005, but we have much better things with bookmarks, histedit, and rebase and even with hg commit --amend. Evolve is basically the last nail in MQ's coffin.
    - laureny 12y ago
      Which is why every single tutorial of rebase you can find will explain that you should never rebase branches that have already been published.
      - scott_karana 12y ago
        Yes. We were discussing the advantages of Mercurial having publishable rebases.
  - CyberShadow 12y ago
    Technically git has this too, although not in a very user-friendly form: http://git-scm.com/blog/2010/03/17/replace.html http://git-scm.com/blog/2010/03/17/replace.html It requires some manual setup on all checkouts for the changes to propagate automatically.
    - jordigh 12y ago
      This is not the same. Well, it's sort of the same infrastructure, but it would require a lot of work to actually work like hg evolve. With Evolve, there is something similar to .git/refs/replace, called obsolescence markers, which may or may not indicate which commit replaces the obsolete commit (some commits are replaced, others are just pruned). These markers are created automatically every time you rewrite history. They don't have to be created manually like with git replace. Moreover, the obsolete commits are hidden from the UI unless you pass the --hidden argument to commands. Lastly, these obsolescence markers are propagated with push and pull operations. It doesn't seem to me like git replace can work over the wire?
      - CyberShadow 12y ago
        > It doesn't seem to me like git replace can work over the wire? I thought that being in the /refs/ namespace would make them eligible for easy synchronization once set up, but on second thought it doesn't seem like it. Git examines parents of refs to determine when something needs to be updated, but would use the parent of the object replacement in this case. I think a mechanism similar to "git notes" would be better, where the ref points to a history of commits with each tree containing files for each replaced object. I've hacked git to do this at one point so we could retroactively edit git commit messages, but abandoned the effort after discovering "git notes".
  - bru 12y ago
    Could you explain this difference to a git user?
    - kyrra 12y ago
      Changeset evolution doesn't actually delete the entries in the history log. Rather it is a commit that changes what history looks like at a certain point in time. There are CLI commands to show the commits that are actually obsolete or have been rewritten. Since it's really a commit that changes what history looks like, it's safe to push to other users. More details here: http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
    - gizmogwai 12y ago
      In git, when you rewrite your history, the old version is gone (well, you still have the revlog for 30 days, but then it's basically over). This is why some commands like `git push --force`after a rebase can cause so much hassle to a community (hello Jenkins!) Here, the principle is te keep all the history, and its rewrites, forever, and to ease the distribution of those changesets.
      - Crito 12y ago
        Nitpick: The old version will not be gone unless it is no longer reachable from any of the refs. Making it no longer reachable from merely one of many refs will not cause it to be GC'd. This isn't really a nitpick though, since this means that similar porcelain could be implemented on top of git fairly easily. The underlying data-model supports it.
    - mrtngslr 12y ago
      From: https://plus.google.com/+MartinGeisler/posts/eR6obsGwTGw https://plus.google.com/+MartinGeisler/posts/eR6obsGwTGw Changeset evolution has some similarities with a distributed reflog. Like Git, commits are immutable in Mercurial and we can only "change" a commit by creating a new version and then hide the old version. Mercurial "hides" the old version today by stripping it from the repository — the old version is then stored in a bundle in the .hg/strip-backups folder. This is far from optimal, so a first step was to add a concept of hidden commits. Hidden changesets have been part of core Mercurial for some time now. The evolve extension enables it and actually changes commands to use it. So "hg commit --amend" will normally strip the old commit, but when evolve is enabled, it will instead hide it. This is both faster and safer. The next step is the introduction obsolete markers. These are small markers that tell you when a commit is succeeded by a better version. When you amend a commit, an obsolete marker will be created that say "the new version obsoleted the old version". This information is something that Git doesn't store, and it is by distributing these markers that we can make Mercurial more intelligent. As an example, if I amend a commit that you have already based work on, then evolve will know that it should rebase your work onto the successor I created. It will tell you about this when you pull from me and get the new version along with the obsolete marker. Your commits will be called "unstable" as that point, meaning that they are descendants of a commit marked obsolete (they descend from the commit I amended and thus marked obsolete). You can run "hg evolve" and it will figure out that it should run "hg rebase" behind the scenes. Seen like this, I would say evolve is similar to what happens in Git when you edit history, but with some extra meta data that will allow you to edit shared history with confidence.
  - VoiceOfWisdom 12y ago
    Exactly! The fact that Git allows you to destructively rewrite history public history is EVIL. Not every user of revision control is going to have a Phd in Not Fucking Up The Repo and I never want a situation like the Jenkins devs had[1] to occur with my projects. [1] https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742
    - Crito 12y ago
      "Git", (really, whatever git server you are using for your publicly accessible repo) only allows you to do that if you allow it to allow you to do that. Rejecting non-fast-forward commits is standard practice in every git shop that I've worked in.
      - davvid 12y ago
        It's also the default these days. $ git init --bare --shared foo.git Initialized empty shared Git repository in foo.git/ $ cat foo.git/config # ... [receive] denyNonFastforwards = true
        anton_gogolev 12y ago
        I love just how persistent is Git in confusing users. Double negative, anyone?
        tsm 12y ago
        It's not a double negative...denying non-FFs != allowing FFs.
        pdhborges 12y ago
        why not: [receive] onlyFastForwards = true
        timv 12y ago
        The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=true"
  - __david__ 12y ago
    I was impressed and excited when I read about that feature, but as I chewed on it for a while I realized I don't think I would ever use it. Most of my history rewriting is done locally before I've ever pushed—in that case I don't want those kept track of because they are throwaway (the same reason I don't check in a file after every single character change). For the case when you want to push out to the world… Well, that's mostly for catastrophic things—oh, no I accidentally checked in the private key! In that case I also don't want the history of that kept around. So I don't know. I like the idea, but I'm not sure when it's applicable.
    - jordigh 12y ago
      >Most of my history rewriting is done locally before I've ever pushed That's just a habit you acquired because right now rewriting public history is a "problem". It shouldn't be a problem. In fact, it's something people do, e.g. how about being able to edit a pull request as it's being discussed and it being ok if that pull request gets merged as it's being discussed?
      - __david__ 12y ago
        Perhaps, but I think it's more fundamental than that. Like I said earlier, I don't save after ever character or word typed into a file, and I don't even commit changes until I think they might be ready. I don't push until it works (for some definition of "works" depending on how lazy I am and what project it is). There are all these different levels of "saveyness" and the lower levels are just not as interesting. In particular, I don't want stupid untested typos in the commit history because they just aren't interesting or helpful. But I'm willing to say that I'm probably missing something… I just don't see what it is yet. :-)
        ezquerra 12y ago
        When you enable mercurial's evolve, history rewriting operations are no longer destructive. Mercurial's evolve creates a sort of repository "meta history" by saving every revision before you modify it (e.g. by using amend). It makes those saved, old versions "obsolete" and it "hides" them (so that they won't show on your DAG when you do "hg log", for example, unless you use the --hidden flag). Evolve also keeps track of the relationship between obsolete revisions and their "successors". That is, it will know whether a certain revision in your DAG is the result of amending one revision, or perhaps of folding several revisions into one, or splitting one revision in two or perhaps just removing a revision from the DAG (this is what I called repository meta history above). Those hidden, obsolete revisions are not shown on your DAG and they are generally not pushed nor pulled. In most respects they behave as if they were not even there. It is only when you need them that you can show them or go back to them (by using the --hidden flag of some of mercurial's command such as hg log or hg update). This gives you a nice safety net (since rewriting history is no longer a destructive operation) that you can use _if you want_. It also makes it possible to rewrite revisions that you have already shared with other users (since when you push a successor revision you also push the list of revisions that it is the successor of). I think evolve is a significant step forward on the DVCS paradigm as it enables safe, distributed, collaborative history rewriting. This is something that, AFAIK, was not possible up until now.
  - JoshTriplett 12y ago
    > I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history. That can be a feature or a bug. This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites. On the other hand, most users who locally use git rebase -i to transform a local series of WIP patches into a sensible patch series for submission do not want any record of the intermediate commits (which may not bisect, or even build, and which may have commit messages like "WIP: try fixing it again"). git makes it easy and sensible to commit early and often, and then sort out a sensible patch series from the result.
    - merijnv 12y ago
      This is of course a straw man as Mercurial already has several tools for this (MQ, rebase, histedit), which will keep working as-is even with changeset evolution. So changeset evolution allows things in addition to the local rebasing.
      - ngoldbaum 12y ago
        Not only that, but outdated changes aren't shared by clone or pull unless you explicitly ask for them. The full history stays on the server but intermediate commits slowly fade away as users hardly ever pull them.
- jordigh 12y ago
  I gave a talk about it at our local Python user group. AMA: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg
  - stonemetal 12y ago
    Is history modifying rebase going away? If I accidently commit "the keys to the kingdom" how do I get them out of the history?
    - ngoldbaum 12y ago
      You can still permanently delete a changeset using `hg strip`. Of course if you have pushed that changeset you will need to run `hg strip` on all remote repositories that have a copy of the commit. Mercurial will also (very helpfully) create a backup bundle of the changeset you strip, so you will need to securely erase that as well.
    - jordigh 12y ago
      > Is history modifying rebase going away? In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. With evolve, the obsolete commits stay around foreverish, but they slowly fade from history as new people clone or pull, since obsolete commits don't get pulled or pushed by default. > If I accidently commit "the keys to the kingdom" how do I get them out of the history? Mercurial never actually removes any functionality, since it's got the deepest commitment to backwards compatibility I've ever seen. Thus, you will delete commits the same way you do now: hg strip --no-backup. That deletes commits with extreme prejudice, locally. Now you just have to run this in every copy of your repo, including remote ones, but the genie-out-of-the-bottle problem is one you can't avoid with a DVCS.
      - Skinney 12y ago
        > In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. rebase doesn't mean "rewrite commits", it means "create new commits based on these ones, based of a new base". Your original commits are still there, and are pushed to the remote, but are GCed after a certain period (default 30 days?) if they are not referenced from anywhere. Since unreferenced commits are pushed to the remote, you can easily restore those commits within the GC period.
EGreg 12y ago
Changeset evolution puts mercurial slightly ahead of git here Now if only Atlassian's bitbucket was as popular as github!
- anton_gogolev 12y ago
  I'd say that with Phases[1] and Publishing vs. Non-Publishing Repositories[2] Mercurial is already ahead of Git in terms of safe history rewriting. Changeset Evolution is significantly more powerful than anything Git has to offer. [1]: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases [2]: http://mercurial.selenic.com/wiki/PublishingRepositories http://mercurial.selenic.com/wiki/PublishingRepositories
- ngoldbaum 12y ago
  Sadly bitbucket does not have very good support for features from "modern" mercurial like bookmarks and changeset evolution. Since most of their users are git users I don't think they are strongly motivated to shore up mercurial support.
  - jordigh 12y ago
    Their devs hang out in #mercurial in Freenode and have been talking about how to implement Evolve on the bitbucket WUI.
    - ngoldbaum 12y ago
      Good to know! I'm looking forward to more news on that front.
  - bobmoretti 12y ago
    The advantage of changeset evolution is obvious to me. But as a longtime Mercurial user, I don't grok the benefit of bookmarks. Do you have a simple example where a bookmark is more useful than a permanent branch?
    - 12y ago
brianolson 12y ago
See also : http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.0-rc_.282014-04-17.29 http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.0-rc_...
wirrbel 12y ago
While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just cant wrap my head around (granted I only use it occasionally). As a platform I like how all the porcellain in mercurial is implemented in a high level python. I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.
- jordigh 12y ago
  > I can only wonder how productive writing custom porcellain commands in mercurial is given that interface. You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git. The stdout of hg is guaranteed to remain stable, so you can script it by just parsing stdout. The options are guaranteed to remain stable, so your old tools won't need to be updated in case hg's CLI some day changes, because its CLI never changes. There are also a bunch of hg CLI commands that start with debug (e.g. hg debugparents or hg debugdag) that you can use to directly manipulate hg's internal revlog data structure and do fun things like create a corrupt repo, if that's what you want to do. :-)
  - wirrbel 12y ago
    I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.). Any first hand experiences with this?
    - jordigh 12y ago
      Sure. Here is a silly example that adds a lol() revset to Mercurial that fetches all prime revision numbers: http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py
BenefitOfDoubt 12y ago
Is Mercurial the BetaMax of source control? Better technically, but didn't have the promotion that Linus gave to Git when he copied much of what Mercurial and other systems had and added a bit of his own flavor.
philtar 12y ago
Can someone explain why the push in the example (that people familiar with hg would recognize) failed?
- joch 12y ago
  There was no default remote defined, since it was a newly created repository and was not cloned from a server.
- anton_gogolev 12y ago
  There are a couple of settings in repository-level configuration file which tell Mercurial where to pull from (`default`) and where to push to (`default-push` or `default`; think "remotes" in Git parlance): [paths] default = http://live.hglabhq.com/hg/hgsharp/hgsharp default-push = http://live.hglabhq.com/hg/hgsharp/hgsharp When you create a new repository with `hg init`, the `[paths]` section is, naturally, empty, hence the complaining.
tomlu 12y ago
I feel like Mercurial still has a chance to become a real force if it can provably solve some of the real issues with git. It won't do to just have a nicer CLI since most people are used to git by now. Here are some of git's real problems: * Performance issues with multi-GB git repos * Handling of large binary files * Submodules - Mercurial has subrepos, but I don't know how they compare
- colechristensen 12y ago
  There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control. I'd like to see a second class of files which are only checksummed (or timestamped) on 'status', 'diff', 'add' and then binary-diffed on commit for possible compression (or perhaps deduped with checksums of blocks) with features like 'git/hg binary-add somefile.jar' to differentiate.
  - mintplant 12y ago
    Check out git-annex: https://git-annex.branchable.com/how_it_works/ https://git-annex.branchable.com/how_it_works/ It operates under a similar principle (committing hashes rather than file contents) but stores the actual file contents elsewhere rather than using a compression/deduplication within the repo itself.
    - colechristensen 12y ago
      I have. It's neat, but it's more about replacing something like Dropbox than it is replacing git (despite being based on git). It also isn't particularly stable, though I have nothing but respect for the developer.
      - AceJohnny2 12y ago
        As I understand it, it became something to replace Dropbox after Joey realized that git-annex's task of distributed storage of large files intersected with the Dropbox use-case, but it didn't start that way, and IMHO doesn't exclude the parent's suggestion. I backed Joey's kickstarter, but to my shame I have yet to give git-annex-assistant a spin.
frik 12y ago
Has Facebook switched to Mercurial? In one news it says so, in the next one read it has a ~50GB Git repo. If they really switched, it would be a good advertisement for Mercurial and its capabilities.
- alwillis 12y ago
  Seems like they’re in the process of switching; they have lots of code to migrate: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
ksec 12y ago
Has any of those Facebook Performance patch been merged with 3.0 yet?
- mrtngslr 12y ago
  Yes, they are merged. The Facebook guys have been doing a great job optimizing things all over the place (revsets in particular).

226 points by anton_gogolev 12y ago

I am so excited for Changset Evolution. The only thing I miss having from git in mercurial, is the ability to safely rewrite commit history.

krallja 12y ago
I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.
- scott_karana 12y ago
  I agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere.
  - mpdehaan2 12y ago
    This is probably due to an understanding of rebases, rebases should be used to bring your commits to the top of the stack for easy review in OSS projects. Amazingly useful for making sure patches are easy to apply while following a remote branch. My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local branches more sane -- but it's frustrating because it's not the same thing.
    - Crito 12y ago
      Wait, "quilt" as in the tool that manages patch files? That's still in use? Or is quilt a new Hg extension?
      - mpdehaan2 12y ago
        I think I meant queues. I was looking for the plugin and failing to find it, but it was basically a thing like quilt but an Hg extension. Was not a fan :)
    - jordigh 12y ago
      > and having to use things like quilt on top to try to make local branches more sane I consider Mercurial Queues as one of Mercurial's youthful mistakes. It was ok in 2005, but we have much better things with bookmarks, histedit, and rebase and even with hg commit --amend. Evolve is basically the last nail in MQ's coffin.
  - laureny 12y ago
    Which is why every single tutorial of rebase you can find will explain that you should never rebase branches that have already been published.
    - scott_karana 12y ago
      Yes. We were discussing the advantages of Mercurial having publishable rebases.
- CyberShadow 12y ago
  Technically git has this too, although not in a very user-friendly form: http://git-scm.com/blog/2010/03/17/replace.html http://git-scm.com/blog/2010/03/17/replace.html It requires some manual setup on all checkouts for the changes to propagate automatically.
  - jordigh 12y ago
    This is not the same. Well, it's sort of the same infrastructure, but it would require a lot of work to actually work like hg evolve. With Evolve, there is something similar to .git/refs/replace, called obsolescence markers, which may or may not indicate which commit replaces the obsolete commit (some commits are replaced, others are just pruned). These markers are created automatically every time you rewrite history. They don't have to be created manually like with git replace. Moreover, the obsolete commits are hidden from the UI unless you pass the --hidden argument to commands. Lastly, these obsolescence markers are propagated with push and pull operations. It doesn't seem to me like git replace can work over the wire?
    - CyberShadow 12y ago
      > It doesn't seem to me like git replace can work over the wire? I thought that being in the /refs/ namespace would make them eligible for easy synchronization once set up, but on second thought it doesn't seem like it. Git examines parents of refs to determine when something needs to be updated, but would use the parent of the object replacement in this case. I think a mechanism similar to "git notes" would be better, where the ref points to a history of commits with each tree containing files for each replaced object. I've hacked git to do this at one point so we could retroactively edit git commit messages, but abandoned the effort after discovering "git notes".
- bru 12y ago
  Could you explain this difference to a git user?
  - kyrra 12y ago
    Changeset evolution doesn't actually delete the entries in the history log. Rather it is a commit that changes what history looks like at a certain point in time. There are CLI commands to show the commits that are actually obsolete or have been rewritten. Since it's really a commit that changes what history looks like, it's safe to push to other users. More details here: http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
  - gizmogwai 12y ago
    In git, when you rewrite your history, the old version is gone (well, you still have the revlog for 30 days, but then it's basically over). This is why some commands like `git push --force`after a rebase can cause so much hassle to a community (hello Jenkins!) Here, the principle is te keep all the history, and its rewrites, forever, and to ease the distribution of those changesets.
    - Crito 12y ago
      Nitpick: The old version will not be gone unless it is no longer reachable from any of the refs. Making it no longer reachable from merely one of many refs will not cause it to be GC'd. This isn't really a nitpick though, since this means that similar porcelain could be implemented on top of git fairly easily. The underlying data-model supports it.
  - mrtngslr 12y ago
    From: https://plus.google.com/+MartinGeisler/posts/eR6obsGwTGw https://plus.google.com/+MartinGeisler/posts/eR6obsGwTGw Changeset evolution has some similarities with a distributed reflog. Like Git, commits are immutable in Mercurial and we can only "change" a commit by creating a new version and then hide the old version. Mercurial "hides" the old version today by stripping it from the repository — the old version is then stored in a bundle in the .hg/strip-backups folder. This is far from optimal, so a first step was to add a concept of hidden commits. Hidden changesets have been part of core Mercurial for some time now. The evolve extension enables it and actually changes commands to use it. So "hg commit --amend" will normally strip the old commit, but when evolve is enabled, it will instead hide it. This is both faster and safer. The next step is the introduction obsolete markers. These are small markers that tell you when a commit is succeeded by a better version. When you amend a commit, an obsolete marker will be created that say "the new version obsoleted the old version". This information is something that Git doesn't store, and it is by distributing these markers that we can make Mercurial more intelligent. As an example, if I amend a commit that you have already based work on, then evolve will know that it should rebase your work onto the successor I created. It will tell you about this when you pull from me and get the new version along with the obsolete marker. Your commits will be called "unstable" as that point, meaning that they are descendants of a commit marked obsolete (they descend from the commit I amended and thus marked obsolete). You can run "hg evolve" and it will figure out that it should run "hg rebase" behind the scenes. Seen like this, I would say evolve is similar to what happens in Git when you edit history, but with some extra meta data that will allow you to edit shared history with confidence.
- VoiceOfWisdom 12y ago
  Exactly! The fact that Git allows you to destructively rewrite history public history is EVIL. Not every user of revision control is going to have a Phd in Not Fucking Up The Repo and I never want a situation like the Jenkins devs had[1] to occur with my projects. [1] https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742
  - Crito 12y ago
    "Git", (really, whatever git server you are using for your publicly accessible repo) only allows you to do that if you allow it to allow you to do that. Rejecting non-fast-forward commits is standard practice in every git shop that I've worked in.
    - davvid 12y ago
      It's also the default these days. $ git init --bare --shared foo.git Initialized empty shared Git repository in foo.git/ $ cat foo.git/config # ... [receive] denyNonFastforwards = true
      - anton_gogolev 12y ago
        I love just how persistent is Git in confusing users. Double negative, anyone?
        tsm 12y ago
        It's not a double negative...denying non-FFs != allowing FFs.
        pdhborges 12y ago
        why not: [receive] onlyFastForwards = true
        timv 12y ago
        The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=true"
- __david__ 12y ago
  I was impressed and excited when I read about that feature, but as I chewed on it for a while I realized I don't think I would ever use it. Most of my history rewriting is done locally before I've ever pushed—in that case I don't want those kept track of because they are throwaway (the same reason I don't check in a file after every single character change). For the case when you want to push out to the world… Well, that's mostly for catastrophic things—oh, no I accidentally checked in the private key! In that case I also don't want the history of that kept around. So I don't know. I like the idea, but I'm not sure when it's applicable.
  - jordigh 12y ago
    >Most of my history rewriting is done locally before I've ever pushed That's just a habit you acquired because right now rewriting public history is a "problem". It shouldn't be a problem. In fact, it's something people do, e.g. how about being able to edit a pull request as it's being discussed and it being ok if that pull request gets merged as it's being discussed?
    - __david__ 12y ago
      Perhaps, but I think it's more fundamental than that. Like I said earlier, I don't save after ever character or word typed into a file, and I don't even commit changes until I think they might be ready. I don't push until it works (for some definition of "works" depending on how lazy I am and what project it is). There are all these different levels of "saveyness" and the lower levels are just not as interesting. In particular, I don't want stupid untested typos in the commit history because they just aren't interesting or helpful. But I'm willing to say that I'm probably missing something… I just don't see what it is yet. :-)
      - ezquerra 12y ago
        When you enable mercurial's evolve, history rewriting operations are no longer destructive. Mercurial's evolve creates a sort of repository "meta history" by saving every revision before you modify it (e.g. by using amend). It makes those saved, old versions "obsolete" and it "hides" them (so that they won't show on your DAG when you do "hg log", for example, unless you use the --hidden flag). Evolve also keeps track of the relationship between obsolete revisions and their "successors". That is, it will know whether a certain revision in your DAG is the result of amending one revision, or perhaps of folding several revisions into one, or splitting one revision in two or perhaps just removing a revision from the DAG (this is what I called repository meta history above). Those hidden, obsolete revisions are not shown on your DAG and they are generally not pushed nor pulled. In most respects they behave as if they were not even there. It is only when you need them that you can show them or go back to them (by using the --hidden flag of some of mercurial's command such as hg log or hg update). This gives you a nice safety net (since rewriting history is no longer a destructive operation) that you can use _if you want_. It also makes it possible to rewrite revisions that you have already shared with other users (since when you push a successor revision you also push the list of revisions that it is the successor of). I think evolve is a significant step forward on the DVCS paradigm as it enables safe, distributed, collaborative history rewriting. This is something that, AFAIK, was not possible up until now.
- JoshTriplett 12y ago
  > I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history. That can be a feature or a bug. This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites. On the other hand, most users who locally use git rebase -i to transform a local series of WIP patches into a sensible patch series for submission do not want any record of the intermediate commits (which may not bisect, or even build, and which may have commit messages like "WIP: try fixing it again"). git makes it easy and sensible to commit early and often, and then sort out a sensible patch series from the result.
  - merijnv 12y ago
    This is of course a straw man as Mercurial already has several tools for this (MQ, rebase, histedit), which will keep working as-is even with changeset evolution. So changeset evolution allows things in addition to the local rebasing.
    - ngoldbaum 12y ago
      Not only that, but outdated changes aren't shared by clone or pull unless you explicitly ask for them. The full history stays on the server but intermediate commits slowly fade away as users hardly ever pull them.
jordigh 12y ago
I gave a talk about it at our local Python user group. AMA: https://www.youtube.com/watch?v=4OlDm3akbqg https://www.youtube.com/watch?v=4OlDm3akbqg
- stonemetal 12y ago
  Is history modifying rebase going away? If I accidently commit "the keys to the kingdom" how do I get them out of the history?
  - ngoldbaum 12y ago
    You can still permanently delete a changeset using `hg strip`. Of course if you have pushed that changeset you will need to run `hg strip` on all remote repositories that have a copy of the commit. Mercurial will also (very helpfully) create a backup bundle of the changeset you strip, so you will need to securely erase that as well.
  - jordigh 12y ago
    > Is history modifying rebase going away? In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. With evolve, the obsolete commits stay around foreverish, but they slowly fade from history as new people clone or pull, since obsolete commits don't get pulled or pushed by default. > If I accidently commit "the keys to the kingdom" how do I get them out of the history? Mercurial never actually removes any functionality, since it's got the deepest commitment to backwards compatibility I've ever seen. Thus, you will delete commits the same way you do now: hg strip --no-backup. That deletes commits with extreme prejudice, locally. Now you just have to run this in every copy of your repo, including remote ones, but the genie-out-of-the-bottle problem is one you can't avoid with a DVCS.
    - Skinney 12y ago
      > In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. rebase doesn't mean "rewrite commits", it means "create new commits based on these ones, based of a new base". Your original commits are still there, and are pushed to the remote, but are GCed after a certain period (default 30 days?) if they are not referenced from anywhere. Since unreferenced commits are pushed to the remote, you can easily restore those commits within the GC period.

EGreg 12y ago

Changeset evolution puts mercurial slightly ahead of git here Now if only Atlassian's bitbucket was as popular as github!

anton_gogolev 12y ago
I'd say that with Phases[1] and Publishing vs. Non-Publishing Repositories[2] Mercurial is already ahead of Git in terms of safe history rewriting. Changeset Evolution is significantly more powerful than anything Git has to offer. [1]: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases [2]: http://mercurial.selenic.com/wiki/PublishingRepositories http://mercurial.selenic.com/wiki/PublishingRepositories
ngoldbaum 12y ago
Sadly bitbucket does not have very good support for features from "modern" mercurial like bookmarks and changeset evolution. Since most of their users are git users I don't think they are strongly motivated to shore up mercurial support.
- jordigh 12y ago
  Their devs hang out in #mercurial in Freenode and have been talking about how to implement Evolve on the bitbucket WUI.
  - ngoldbaum 12y ago
    Good to know! I'm looking forward to more news on that front.
- bobmoretti 12y ago
  The advantage of changeset evolution is obvious to me. But as a longtime Mercurial user, I don't grok the benefit of bookmarks. Do you have a simple example where a bookmark is more useful than a permanent branch?
  - 12y ago

brianolson 12y ago

See also : http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.0-rc_.282014-04-17.29 http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.0-rc_...

wirrbel 12y ago

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just cant wrap my head around (granted I only use it occasionally). As a platform I like how all the porcellain in mercurial is implemented in a high level python. I can only wonder how productive writing custom porcellain commands in mercurial is given that interface.

jordigh 12y ago
> I can only wonder how productive writing custom porcellain commands in mercurial is given that interface. You don't have to use Python to add more commands on top of Mercurial. Its CLI is also its API, just like git, and you don't typically have to use Python to write tools on top of hg, just like you don't typically need to write C to hack on top of git. The stdout of hg is guaranteed to remain stable, so you can script it by just parsing stdout. The options are guaranteed to remain stable, so your old tools won't need to be updated in case hg's CLI some day changes, because its CLI never changes. There are also a bunch of hg CLI commands that start with debug (e.g. hg debugparents or hg debugdag) that you can use to directly manipulate hg's internal revlog data structure and do fun things like create a corrupt repo, if that's what you want to do. :-)
- wirrbel 12y ago
  I probably should have phrased this more clearly: I think that a python interface (or any other high level script interface) is the more convenient way for a programmer to extend or write hooks/extend the dcvs (I am now thinking about pre commit or post commit hooks in git, etc.). Any first hand experiences with this?
  - jordigh 12y ago
    Sure. Here is a silly example that adds a lol() revset to Mercurial that fetches all prime revision numbers: http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py http://inversethought.com/hg/revset/file/2ddbf1893f3b/lol.py

BenefitOfDoubt 12y ago

Is Mercurial the BetaMax of source control? Better technically, but didn't have the promotion that Linus gave to Git when he copied much of what Mercurial and other systems had and added a bit of his own flavor.

philtar 12y ago

Can someone explain why the push in the example (that people familiar with hg would recognize) failed?

joch 12y ago
There was no default remote defined, since it was a newly created repository and was not cloned from a server.
anton_gogolev 12y ago
There are a couple of settings in repository-level configuration file which tell Mercurial where to pull from (`default`) and where to push to (`default-push` or `default`; think "remotes" in Git parlance): [paths] default = http://live.hglabhq.com/hg/hgsharp/hgsharp default-push = http://live.hglabhq.com/hg/hgsharp/hgsharp When you create a new repository with `hg init`, the `[paths]` section is, naturally, empty, hence the complaining.

tomlu 12y ago

I feel like Mercurial still has a chance to become a real force if it can provably solve some of the real issues with git. It won't do to just have a nicer CLI since most people are used to git by now. Here are some of git's real problems: * Performance issues with multi-GB git repos * Handling of large binary files * Submodules - Mercurial has subrepos, but I don't know how they compare

colechristensen 12y ago
There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control. I'd like to see a second class of files which are only checksummed (or timestamped) on 'status', 'diff', 'add' and then binary-diffed on commit for possible compression (or perhaps deduped with checksums of blocks) with features like 'git/hg binary-add somefile.jar' to differentiate.
- mintplant 12y ago
  Check out git-annex: https://git-annex.branchable.com/how_it_works/ https://git-annex.branchable.com/how_it_works/ It operates under a similar principle (committing hashes rather than file contents) but stores the actual file contents elsewhere rather than using a compression/deduplication within the repo itself.
  - colechristensen 12y ago
    I have. It's neat, but it's more about replacing something like Dropbox than it is replacing git (despite being based on git). It also isn't particularly stable, though I have nothing but respect for the developer.
    - AceJohnny2 12y ago
      As I understand it, it became something to replace Dropbox after Joey realized that git-annex's task of distributed storage of large files intersected with the Dropbox use-case, but it didn't start that way, and IMHO doesn't exclude the parent's suggestion. I backed Joey's kickstarter, but to my shame I have yet to give git-annex-assistant a spin.

frik 12y ago

Has Facebook switched to Mercurial? In one news it says so, in the next one read it has a ~50GB Git repo. If they really switched, it would be a good advertisement for Mercurial and its capabilities.

alwillis 12y ago
Seems like they’re in the process of switching; they have lots of code to migrate: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

ksec 12y ago

Has any of those Facebook Performance patch been merged with 3.0 yet?

mrtngslr 12y ago
Yes, they are merged. The Facebook guys have been doing a great job optimizing things all over the place (revsets in particular).