4 ms·

This suck big time. HG is by far the best UX of all SCM I have used. Without bitbucket I think usage of hg will drop even faster. The sad thing is that git re

• umvi 7y ago
  > The sad thing is that git requiere so much arcane usage that hg have spared me for so much time. Like what? I've been using git for 5 years and I hardly ever stray from the set {push, pull, reset, checkout, rebase}. I use VSCode for staging, committing, diffing, etc. though, so that probably spares me some commands, but I rarely (if ever?) have had to do what I would consider an "arcane" command. > Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them? Git has improved over time. Why, in the latest release they improved UX for the "checkout" command. Before it could mean "switch branch" or "restore file" but now there are 2 explicit commands: "git switch" (for switching branches) and "git restore" (for restoring files).
  • Siecje 7y ago
    How do you create a new branch? Still git checkout -b?
    • umvi 7y ago
      Under the new commands you would either do: `git branch <branch name> && git switch <branch name>` or `git switch -c <branch name>` (create and switch)
    • deleted 7y ago
      [deleted]
• carapace 7y ago
  I'd like git internals (merkle-tree etc.) with Mercurial's CLI UI, I think.
  • nemetroid 7y ago
    It's quite possible to write your own Git CLI, the fundamentals are well exposed.
    • carapace 7y ago
      That's a good point. I could probably strap together click and Dulwich and bang out something in a day or two. https://palletsprojects.com/p/click/ https://palletsprojects.com/p/click/ https://click.palletsprojects.com/en/7.x/ https://click.palletsprojects.com/en/7.x/ https://www.dulwich.io/ https://www.dulwich.io/
    • ntobjx 7y ago
      It works until it doesn't. One of the biggest problems with Git IMO is that it always exposed a plethora of internals which therefore have become public interfaces. One is to be expected to know the guts of .git as an intermediate/advanced user. And because those are interfaces, it's _always_ going to be very difficult to fix issues arising from previous wrong design decisions. Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll get by with a dozen or so command line invocations overall. And I found it astonishing and disheartening how so many people were able to make do with completely illogical commands like "git checkout -b" ... But once Git sticks you the finger and you _need_ to delve down into its guts, you often have a problem. Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and web interfaces like GitHub glossing over numerous shortcomings of Git have certainly helped the UX and the popularity. But once you _have to_ delve down to CLI usage because you ran into an issue that your tool tries to gloss over, most people are at a loss. And most people will opt to scrap the current clone+worktree and clone anew. That doesn't really sound to me like people are in command of their tool of choice (Git), though. And at this point we haven't even touched stuff like refs which only differ in case. It's all fine until Git starts unpacking the refs. Which can be fun on systems like macOS and Windows which have support for case-sensitivity in the file system, but who opted to forgo that via a setting.
• flukus 7y ago
  > Don't tell me is for "speed" or "features" In this case it was speed. Git respected the time of it's users and hg respected the time of it's developers more, it's in no way surprising that users picked git. > The sad thing is that git requiere so much arcane usage that hg have spared me for so much time. IME the only people that struggle with git are people that refuse to learn it, properly learn it and not "pick it up as you go". It's such a small time investment that pays off for any professional.
• ntobjx 7y ago
  The buzzwordiest always win because managers seem to rely on whatever comes up first in a web search. And that's typically Scrum, not Kanban. It's Git, not Mercurial. Managers won't have to work with the tools they impose on their subordinates. It's the subordinates who have to. But I have also noticed how a lot of people profess to "like" Git for spurious reasons like because it's (allegedly) "so powerful", but then they stick to the simplest workflow possible, because they don't have a clue about intermediate or advanced uses. But that same logic can seemingly also be applied to why C++ "won" (not that I dislike C++ as much as Git, though). The charm is in how powerful it seems to be, but then you use loads of third-party abstractions and throw the alleged performance benefits out of the window. For an SCM tool I want it to stay out of my way. It's meant to assist me in doing my main job. An SCM should not require my attention all the time because of the shitty CLI, inconsistent subcommands, horrible and incomplete documentation seeping with tool-specific terminology (see man gitglossary) and incomplete (or unidirectional) support for important features (git clone [here] [there], git push to remote with worktree). Git manages to always require ones attention, and typically in the worst way possible.