4 ms·

While I don't consider myself a wiz, I'm fairly proficient at both (was responsible for stuff like lfs and submodule reorganization on git in my previous job).

While I don't consider myself a wiz, I'm fairly proficient at both (was responsible for stuff like lfs and submodule reorganization on git in my previous job). I'm honestly surprised that someone adept at one would struggle with the other: you basically just need to understand the semantical differences in branching. On windows, hg plays much nicer with powershell (ok, so clean is an extension, otoh hg -nu | rm).

philjohn 8y ago
It's not even that - it's mostly just the commandline interface needing you to learn several arcane commands to do simple operations. Of course, if you understand the underlying data model, they seem far less arcane, but that's the problem with Git that Mercurial doesn't have - you really need to understand what's happening under the hood to get proficient at it, whereas Mercurial has a far saner interface that hides the internals under a better abstraction.
- jazzyjackson 8y ago
  I agree with this, but OTOH, in my experience git actually has a nice smooth learning curve for a little while until you hit your first 'wtf did did I just do' snag. I just know on my team or 5 much less technical people, the concept of version control and how to do operations in Mercury was near impossible and it fell on one person to manage merging files with master. Also, this was a distance learning course where the head institution (MIT Media Lab) was keeping a central repo of every location's additions, and the changes made the repo so big that we had hard caps on how much data we could upload. Later on, it fell on me to introduce git to some colleagues. Just walking them through 'checkout','branch','merge','push','pull' got them on their feet and contributing to a repo. If they hit a wall, I could help detangle the knot, but at least we were in it together.
- jgraham 8y ago
  I really don't think that mercurial is very good at hiding the internals. Consider a common operation; asking for the commit history. If you type `hg log` you get something very close to a prettified view of the internal datastructure by default; a list of all commits in the repository, in the order they were added, each annotated with a sequence id that's an index into the internal list. So a new user has to learn: * hg log by default doesn't tell them anything about the current code they're working on; it's just a dump of everything. To get the history of the current working copy they need to pass -f which they are learning in other contexts means "do something unsafe". * hg gives commits sequence ids that can locally be used in place of the commit sha, but must never be shared across repositories. In practice at Mozilla I have seen people run into both these issues, causing much unnecessary confusion.

philjohn 8y ago

It's not even that - it's mostly just the commandline interface needing you to learn several arcane commands to do simple operations. Of course, if you understand the underlying data model, they seem far less arcane, but that's the problem with Git that Mercurial doesn't have - you really need to understand what's happening under the hood to get proficient at it, whereas Mercurial has a far saner interface that hides the internals under a better abstraction.

jazzyjackson 8y ago
I agree with this, but OTOH, in my experience git actually has a nice smooth learning curve for a little while until you hit your first 'wtf did did I just do' snag. I just know on my team or 5 much less technical people, the concept of version control and how to do operations in Mercury was near impossible and it fell on one person to manage merging files with master. Also, this was a distance learning course where the head institution (MIT Media Lab) was keeping a central repo of every location's additions, and the changes made the repo so big that we had hard caps on how much data we could upload. Later on, it fell on me to introduce git to some colleagues. Just walking them through 'checkout','branch','merge','push','pull' got them on their feet and contributing to a repo. If they hit a wall, I could help detangle the knot, but at least we were in it together.
jgraham 8y ago
I really don't think that mercurial is very good at hiding the internals. Consider a common operation; asking for the commit history. If you type `hg log` you get something very close to a prettified view of the internal datastructure by default; a list of all commits in the repository, in the order they were added, each annotated with a sequence id that's an index into the internal list. So a new user has to learn: * hg log by default doesn't tell them anything about the current code they're working on; it's just a dump of everything. To get the history of the current working copy they need to pass -f which they are learning in other contexts means "do something unsafe". * hg gives commits sequence ids that can locally be used in place of the commit sha, but must never be shared across repositories. In practice at Mozilla I have seen people run into both these issues, causing much unnecessary confusion.