4 ms·

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.