9 ms·

The biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people

The biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people I've chatted to about it seem to find Mercurial's interface much easier to grok / pick up as a new user than Git's (which is somewhat notorious for its quirks). There are other differences, but these stand out to me. That said, I use Git because adoption + community (and my experience with hg-git has been less successful than some... though it's been a while since I gave it a spin)

marcinkuzminski 10y ago
CTO of RhodeCode here. If you use phases (draft/secret/public) correctly it's really close to being mutable. For example all our devs forks are having non-publishing repositories since it's a private non-shared space. By keeping all commits as draft it's easy to do a rebase and then push new changed commits. While the main repo is publishing and once pushed commits are never mutable, also we keep a workflow that only dev forks can have multiple heads while production repo cant. IMHO it's the nicer form of mutability
- Bjartr 10y ago
  Do you have or know of writeups describing this workflow in more detail? I'm interested in learning more.
  - ngoldbaum 10y ago
    This workflow is described in the documentation for the mercurial evolve extension: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
  - marcinkuzminski 10y ago
    Here's a blog post on how to use Bookmarks in Mercurial workflow using code-review. We back ported from one of the guys that works for us and described our workflow: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use https://rhodecode.com/blog/120/mercurial-workflow-using-book...
jjnoakes 10y ago
Can you elaborate on what you mean by immutable history, and how git lacks it?
- lucideer 10y ago
  In git you can edit past commits and rebase, which completely destroys historical data and traces of the rebase. This can be very useful, e.g. for keeping a frequently-committed-to branch "clean" and informative by squashing commits, for removing accidentally committed sensitive credentials, etc. Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred" truthful account. You still get the same flexibility as git if/when you need the above mutability: it's not 100% immutable, it supports local rebases, and also global mutablity via "phases" - see Marcin's post on this. In an absolute worst case scenario you can also coordinate reclones of a repo of course, but generally speaking the point is that immutability is "on by default".
  - jjnoakes 10y ago
    I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary. And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).
    - jordigh 10y ago
      In git, you `git rebase` any commit will always do whatever you tell it to do. In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server. If you really want to edit public commits, you have to manually force them back to the draft phase before you can rebase or rewrite them.
RandomOpinion 10y ago
To add my 2 cents, immutable history is more of an annoyance than anything. If someone checks in something by mistake that absolutely must be removed (e.g. something that contains a password), it is a considerable undertaking to actually remove that commit from the repository.
- agentgt 10y ago
  It is not hard once you know how to do it is just not readily documented (ie histedit and force push). BTW if you checked in a password... you really should now go change that password :)
  - RandomOpinion 10y ago
    I know better than to check in passwords, thank you very much. Regrettably, some of my colleagues do not.

marcinkuzminski 10y ago

CTO of RhodeCode here. If you use phases (draft/secret/public) correctly it's really close to being mutable. For example all our devs forks are having non-publishing repositories since it's a private non-shared space. By keeping all commits as draft it's easy to do a rebase and then push new changed commits. While the main repo is publishing and once pushed commits are never mutable, also we keep a workflow that only dev forks can have multiple heads while production repo cant. IMHO it's the nicer form of mutability

Bjartr 10y ago
Do you have or know of writeups describing this workflow in more detail? I'm interested in learning more.
- ngoldbaum 10y ago
  This workflow is described in the documentation for the mercurial evolve extension: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/
- marcinkuzminski 10y ago
  Here's a blog post on how to use Bookmarks in Mercurial workflow using code-review. We back ported from one of the guys that works for us and described our workflow: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use https://rhodecode.com/blog/120/mercurial-workflow-using-book...

jjnoakes 10y ago

Can you elaborate on what you mean by immutable history, and how git lacks it?

lucideer 10y ago
In git you can edit past commits and rebase, which completely destroys historical data and traces of the rebase. This can be very useful, e.g. for keeping a frequently-committed-to branch "clean" and informative by squashing commits, for removing accidentally committed sensitive credentials, etc. Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred" truthful account. You still get the same flexibility as git if/when you need the above mutability: it's not 100% immutable, it supports local rebases, and also global mutablity via "phases" - see Marcin's post on this. In an absolute worst case scenario you can also coordinate reclones of a repo of course, but generally speaking the point is that immutability is "on by default".
- jjnoakes 10y ago
  I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary. And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).
  - jordigh 10y ago
    In git, you `git rebase` any commit will always do whatever you tell it to do. In Mercurial, `hg rebase` will abort if you're trying to make it do something to public commits. Public commits are commits that have been shared on a publishing server. The contrast with draft commits, which are commits that have not been shared or only shared on a non-publishing server. If you really want to edit public commits, you have to manually force them back to the draft phase before you can rebase or rewrite them.

RandomOpinion 10y ago

To add my 2 cents, immutable history is more of an annoyance than anything. If someone checks in something by mistake that absolutely must be removed (e.g. something that contains a password), it is a considerable undertaking to actually remove that commit from the repository.

agentgt 10y ago
It is not hard once you know how to do it is just not readily documented (ie histedit and force push). BTW if you checked in a password... you really should now go change that password :)
- RandomOpinion 10y ago
  I know better than to check in passwords, thank you very much. Regrettably, some of my colleagues do not.