4 ms·

If git exposed a consistent, understandable interface to its data model you'd have a point. Mercurial exposes a much more consistent, much more understandable

If git exposed a consistent, understandable interface to its data model you'd have a point. Mercurial exposes a much more consistent, much more understandable interface to a very-similar-to-git data model, so it's not like this is impossible. So it'd be really nice if people could be allowed to point out the shortcomings of git's command-line interface without other people implying their complaints must be rooted in being too dumb and/or too lazy to understand git.

jeremy_wiebe 10y ago
Having never used mercurial. What are some of the places where mercurial provides a better interface than git?
- marcinkuzminski 10y ago
  Just read this: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/ And then think about that Mercurial simply makes handling branches/updates/resets in a very clean and consistent way.
  - amdavidson 10y ago
    Clearly not a new post, but the first time I had seen it, clearly spells out what has frustrated me (and many others) for a very long time.
  - pweissbrod 10y ago
    You really should warn us not to drink anything while reading that. I almost spit my drink over the keyboard laughing at this
- brandmeyer 10y ago
  The basic mercurial command set is directly descended from the time-tested cvs and svn commands. Significantly different tasks are executed with distinct commands. In contrast, git dispatches to a subprogram with the top-level command, and then also gets the subprogram to execute different distinguished tasks with its arguments. Its a rather leaky abstraction that pollutes the command syntax. But since I've said something disparaging about git, I want to balance it out with something nice about it. Git handles remote tracking branches much more nicely than mercurial. For a while I found myself in a mode where I did most of my work on my workstation, saved to a central repository for collaboration, and took a laptop into the lab/field (I'm an embedded developer). Git trivially allows me to handle multiple remotes from the laptop, with one remote referring to the desktop and one referring to the central repository. Since git lays down distinguished branch names automatically for all of (in mercurial terminology) the remote heads, its easy to diff/merge between them as appropriate when I'm in the field. In Hg, its impossible as far as I know. I had to set up multiple clones to track the two.
derefr 10y ago
See my other replies below. I can't edit my above post now, but I'd like to make clear that I wasn't disagreeing that git(1) has a horrible, obtuse interface. When I say to "meet Git where it lives", I mean "ignore git(1) and focus on the merkle-tree datastore it creates." That datastore (to really stretch the analogy) is a toothbrush-head with rather excellent bristles. Used correctly, it can get your teeth very clean. git(1), on the other hand, is a horrible, obtuse handle attached to it. Ignore the handle; focus on the bristles. (What this statement really means, to me personally, is that I'd love nothing more than spending a few months factoring that merkle-tree datastore out of git(1) into its own library—and then writing a new, much lower-level frontend to expose it. That would be "meeting Git where it lives" in a real sense.) But, presuming that none of us have time to do that but need to get Real Work done (and that work, for whatever reason, requires using git(1) instead of Mercurial et al), the best thing you can do to "understand Git" is to not try to understand git(1), but rather to understand that merkle-tree library that exists in a nascent form inside git(1)—and then understand git(1) itself as a bad and leaky wrapper around it. As long as you understand what each command you give is doing to the object pool, you can "see through" git(1) and it will no longer be a mysterious dental-cleaning machine, but rather just a simple toothbrush with a really weird handle you have to finagle to get it into your mouth. Or, to put it another way: as long as you understand the hygienic goal you're attempting to head toward, then you can understand Git in terms of that goal, rather than in terms of its interface. In this case, the "goal" is building up a content-addressible object pool that you can dump a bunch of people's individual commits into as entirely independent trees (which share objects), that can then be compared and worked with. git(1) doesn't make very clear that this is the goal. git(1) explains itself only in terms of how to operate the handle of the merkle-tree toothbrush, and where you point it; not in terms of what the brush is doing (cleaning your teeth.) git(1), learned in a cargo-cult manner or taught by someone only familiar with centralized or patch-based SCM, will not result in clean teeth. You'll just be waving the toothbrush around in your mouth. That's git(1)'s fault, of course. But that doesn't mean there isn't a powerful toothbrush-head there, if you look past the handle.
paulddraper 10y ago
But in git, it's trivial to delete a branch git -D my-branch
- lawpoop 10y ago
  I don't always delete my branches But when I do, I make a branch called 'rm' first

jeremy_wiebe 10y ago

Having never used mercurial. What are some of the places where mercurial provides a better interface than git?

marcinkuzminski 10y ago
Just read this: http://stevelosh.com/blog/2013/04/git-koans/ http://stevelosh.com/blog/2013/04/git-koans/ And then think about that Mercurial simply makes handling branches/updates/resets in a very clean and consistent way.
- amdavidson 10y ago
  Clearly not a new post, but the first time I had seen it, clearly spells out what has frustrated me (and many others) for a very long time.
- pweissbrod 10y ago
  You really should warn us not to drink anything while reading that. I almost spit my drink over the keyboard laughing at this
brandmeyer 10y ago
The basic mercurial command set is directly descended from the time-tested cvs and svn commands. Significantly different tasks are executed with distinct commands. In contrast, git dispatches to a subprogram with the top-level command, and then also gets the subprogram to execute different distinguished tasks with its arguments. Its a rather leaky abstraction that pollutes the command syntax. But since I've said something disparaging about git, I want to balance it out with something nice about it. Git handles remote tracking branches much more nicely than mercurial. For a while I found myself in a mode where I did most of my work on my workstation, saved to a central repository for collaboration, and took a laptop into the lab/field (I'm an embedded developer). Git trivially allows me to handle multiple remotes from the laptop, with one remote referring to the desktop and one referring to the central repository. Since git lays down distinguished branch names automatically for all of (in mercurial terminology) the remote heads, its easy to diff/merge between them as appropriate when I'm in the field. In Hg, its impossible as far as I know. I had to set up multiple clones to track the two.

derefr 10y ago

See my other replies below. I can't edit my above post now, but I'd like to make clear that I wasn't disagreeing that git(1) has a horrible, obtuse interface. When I say to "meet Git where it lives", I mean "ignore git(1) and focus on the merkle-tree datastore it creates." That datastore (to really stretch the analogy) is a toothbrush-head with rather excellent bristles. Used correctly, it can get your teeth very clean. git(1), on the other hand, is a horrible, obtuse handle attached to it. Ignore the handle; focus on the bristles. (What this statement really means, to me personally, is that I'd love nothing more than spending a few months factoring that merkle-tree datastore out of git(1) into its own library—and then writing a new, much lower-level frontend to expose it. That would be "meeting Git where it lives" in a real sense.) But, presuming that none of us have time to do that but need to get Real Work done (and that work, for whatever reason, requires using git(1) instead of Mercurial et al), the best thing you can do to "understand Git" is to not try to understand git(1), but rather to understand that merkle-tree library that exists in a nascent form inside git(1)—and then understand git(1) itself as a bad and leaky wrapper around it. As long as you understand what each command you give is doing to the object pool, you can "see through" git(1) and it will no longer be a mysterious dental-cleaning machine, but rather just a simple toothbrush with a really weird handle you have to finagle to get it into your mouth. Or, to put it another way: as long as you understand the hygienic goal you're attempting to head toward, then you can understand Git in terms of that goal, rather than in terms of its interface. In this case, the "goal" is building up a content-addressible object pool that you can dump a bunch of people's individual commits into as entirely independent trees (which share objects), that can then be compared and worked with. git(1) doesn't make very clear that this is the goal. git(1) explains itself only in terms of how to operate the handle of the merkle-tree toothbrush, and where you point it; not in terms of what the brush is doing (cleaning your teeth.) git(1), learned in a cargo-cult manner or taught by someone only familiar with centralized or patch-based SCM, will not result in clean teeth. You'll just be waving the toothbrush around in your mouth. That's git(1)'s fault, of course. But that doesn't mean there isn't a powerful toothbrush-head there, if you look past the handle.

paulddraper 10y ago

But in git, it's trivial to delete a branch git -D my-branch

lawpoop 10y ago
I don't always delete my branches But when I do, I make a branch called 'rm' first