sure, a number of reasons. hg interface makes sense. there's clear distinction in semantics between commands and flags. that is not the case with git. git dema

sure, a number of reasons. hg interface makes sense. there's clear distinction in semantics between commands and flags. that is not the case with git. git demands being a wizard to be excellent; hg doesn't. hg repos typically are clones of each other: it takes work to not have all changesets replicated everywhere. the implication of that is that there's no forgetting branches; ergo, there's no confusion about what piece of the dag is pushed and what isn't. it's all pushed. hg branches are 'true' branches, as opposed to refs. I could go into depth into how that plays out in better ways than git, but that's more of an actual essay. hg extensions give hg more power - if you really want to get complicated, it's not unbelievably difficult. hg project makes certain guarantees about stability of interface; tooling is easy to develop around that. tooling makes life better, often. as a general rule of thumb, the hg project and experience adopts a principled way of choices; this flows out into the code and experience. it's a very clean and "better is better" way of working.