4 ms·

I think the big summary of this post comes down to, if you don't have something like: [extensions] shelve = histedit = rebase = mq = As a

I think the big summary of this post comes down to, if you don't have something like: [extensions] shelve = histedit = rebase = mq = As a git developer using hg you're going to be frustrated by all the things 'hg doesn't support'. It doesn't actually not support them, they're just (for some reason?) shipped with hg but not turned on by default.

asperous 13y ago
I'm not sure about shelve, but histedit, rebase, and mq are all history modifying extensions. Mercurial differs from git in that it prefers immutable history. The extensions are there if you really need them, not as something you should always setup imo.
- wangweij 13y ago
  Modifying local history is not dangerous, so I think mq is good. Never really used histedit and rebase.
- mrtngslr 13y ago
  I don't think this is true today. Git and Mercurial have the same basic model, which means that a commit is immutable because the identity of a commit is determined by its content. This means that you must re-create a changeset in both systems if you want to "change" it. Mercurial and Git can do this and have been doing it for years. The difference is that Git has a built-in concept of garbage collection whereas Mercurial does not. So commands that modify history in Mercurial must trigger the garbage collection (we call it strip) manually -- and they do, of course. So you wont see any big difference between 'hg rebase' and 'git rebase'. They both build new commits and remove the old commits (in Git they're removed eventually, in Mercurial they're removed immediatedly, but with a backup if you want to restore the pre-rebase state). The latest versions of Mercurial has history modification built-in: you can 'hg commit --amend' without enabling any extensions. The changeset evolution concept will take this even further and allow really cool collaborative editing of shared history.

asperous 13y ago

I'm not sure about shelve, but histedit, rebase, and mq are all history modifying extensions. Mercurial differs from git in that it prefers immutable history. The extensions are there if you really need them, not as something you should always setup imo.

wangweij 13y ago
Modifying local history is not dangerous, so I think mq is good. Never really used histedit and rebase.
mrtngslr 13y ago
I don't think this is true today. Git and Mercurial have the same basic model, which means that a commit is immutable because the identity of a commit is determined by its content. This means that you must re-create a changeset in both systems if you want to "change" it. Mercurial and Git can do this and have been doing it for years. The difference is that Git has a built-in concept of garbage collection whereas Mercurial does not. So commands that modify history in Mercurial must trigger the garbage collection (we call it strip) manually -- and they do, of course. So you wont see any big difference between 'hg rebase' and 'git rebase'. They both build new commits and remove the old commits (in Git they're removed eventually, in Mercurial they're removed immediatedly, but with a backup if you want to restore the pre-rebase state). The latest versions of Mercurial has history modification built-in: you can 'hg commit --amend' without enabling any extensions. The changeset evolution concept will take this even further and allow really cool collaborative editing of shared history.