5 ms·

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.

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.