4 ms·

I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local mi

I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.

api 7y ago
I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?
- AndrewUnmuted 7y ago
  Personally, I like pushing with hg, but I prefer pulling with git. An HgHub service at the scale of GitHub would probably result in massive end-user UX issues but maybe happier developers and repo administrators.
  - e12e 7y ago
    This reminds how pleasant it was to use hg as a git front-end (via an extention[0]) - compared to using the git cli. I think I'll have to revisit and see if that's still the case, and if I can make it work with feature branches etc. Also looks like there's finally python3 support in the recent mercurial 5.0 release. [0] https://hg-git.github.io/ https://hg-git.github.io/
- loeg 7y ago
  > Is hg as fast as git? No. You still have to launch the Python process per command, which is "extremely" slow (relative to C programs). I air-quote extremely because the difference for a single command is small relative to human time, but it matters for automation that invokes many commands. This post is from 2018, and maybe Hg's frontend is written in C or Rust now (I don't follow its development). But if it is still a Python-driven runtime, the same basic criticisms apply: https://mail.python.org/pipermail/python-dev/2018-May/153296.html https://mail.python.org/pipermail/python-dev/2018-May/153296...
- darkpuma 7y ago
  Git isn't really all that fast for what it is. The "git is fast" thing came about as a comparison to non-distributed version control systems, where changing what branch you were working on could involve coordinating with some (often overburdened) server on the other side of the planet. That's not to say git is slow of course. It's just.. basically what you'd expect given it's architecture.
loeg 7y ago
You probably mean local maxima.
- dual_basis 7y ago
  I was referring to an etherial notion of "loss", which is why I said minima.
boomlinde 7y ago
I like git's UX. Anything outside the typical flow is like walking into a garage filled with old stuff you thought you might need again some day, sifting through boxes of gadgets looking for that one thing you actually do need this time. Productive? Maybe not, but the experience is a much broader subject.

I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.

api 7y ago

I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?

AndrewUnmuted 7y ago
Personally, I like pushing with hg, but I prefer pulling with git. An HgHub service at the scale of GitHub would probably result in massive end-user UX issues but maybe happier developers and repo administrators.
- e12e 7y ago
  This reminds how pleasant it was to use hg as a git front-end (via an extention[0]) - compared to using the git cli. I think I'll have to revisit and see if that's still the case, and if I can make it work with feature branches etc. Also looks like there's finally python3 support in the recent mercurial 5.0 release. [0] https://hg-git.github.io/ https://hg-git.github.io/
loeg 7y ago
> Is hg as fast as git? No. You still have to launch the Python process per command, which is "extremely" slow (relative to C programs). I air-quote extremely because the difference for a single command is small relative to human time, but it matters for automation that invokes many commands. This post is from 2018, and maybe Hg's frontend is written in C or Rust now (I don't follow its development). But if it is still a Python-driven runtime, the same basic criticisms apply: https://mail.python.org/pipermail/python-dev/2018-May/153296.html https://mail.python.org/pipermail/python-dev/2018-May/153296...
darkpuma 7y ago
Git isn't really all that fast for what it is. The "git is fast" thing came about as a comparison to non-distributed version control systems, where changing what branch you were working on could involve coordinating with some (often overburdened) server on the other side of the planet. That's not to say git is slow of course. It's just.. basically what you'd expect given it's architecture.

loeg 7y ago

You probably mean local maxima.

dual_basis 7y ago
I was referring to an etherial notion of "loss", which is why I said minima.

boomlinde 7y ago

I like git's UX. Anything outside the typical flow is like walking into a garage filled with old stuff you thought you might need again some day, sifting through boxes of gadgets looking for that one thing you actually do need this time. Productive? Maybe not, but the experience is a much broader subject.