3 ms·
People always claim this in mercurial posts, but it's really hard to tell to what extent this is just that people who are using hg all the time are familiar wit
by jgraham 7y ago
People always claim this in mercurial posts, but it's really hard to tell to what extent this is just that people who are using hg all the time are familiar with the hg commands and so don't notice the problems any more.
As a irregular hg user, I frequently run into (or help others with) issues with the ui, like "why does `hg log require `-f` to do something useful", "how do I refer to the current head commit (protip: it's not `tip`)", "how do I see changes relative to a branch (bookmark) on a remote" and "which set of commands am I supposed to use for history rewriting nowadays and how do they work?".
hg has some nice features, but the idea that it's got a fully intuitive and uniformly well designed interface is, in my experience, a total myth. Which isn't to say that git has a great CLI of course, just that the extent to which hg is better in this area is often overstated.
- WorldMaker 7y agoI think it's also at least somewhat the case that hg had a great CLI when it launched and git had an abysmal CLI when it launched, but over the years and counting "necessary" hg extensions, they've both sort of converged more towards the middle: git's has only gotten better (and really only had room to get better) and hg's has mostly stayed the same, if not slowly gotten worse from the additional "overhead" of extensions. Which is that the difference between the CLIs in the early days were stark contrasts of good and bad, but now they both seem about equally mediocre, but in different ways, when directly contrasted. (Especially with the latest git release finally splitting checkout into switch and restore, they are really on increasingly similar footing.)
- stjohnswarts 7y agoSame, but I don't really have that many different use cases as a developer. I wouldn't want to be the tools guy maintaining it all for 100+ developers though :)