2 ms·
Why? Are there any technical reasons or is it just the nerd-within wich pushes into the "less popular" choice?
by atmosx 11y ago
Why? Are there any technical reasons or is it just the nerd-within wich pushes into the "less popular" choice?
- mcherm 11y agoYes. http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-merc... (For fairness, if you want the arguments in favor of git, try this: http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/ . But honestly, I prefer Mercurial. It doesn't matter, because the vast majority of the people I collaborate with are using Git, but if I could make the choice, I would use Mercurial.)
- pnathan 11y agosure, 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.