6 ms·

How do you consider the UX "nearly identical" or "arguably worse"? The Mercurial CLI has clear, well named commands that are predictable and easy to memorize.

How do you consider the UX "nearly identical" or "arguably worse"? The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it. I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.

loeg 5mo ago
> How do you consider the UX "nearly identical" or "arguably worse"? The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better. > hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick. > I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times. I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.
- kccqzy 5mo ago
  > history is a stream of content-addressed commits Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`. Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.
  - anal_reactor 5mo ago
    You mean "git tag"?
    - dwattttt 5mo ago
      If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git. EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy. A git-native workflow for this would be to have a sequence of branches you continue to update, where 'main' is those branches merged at all times.
      - anal_reactor 5mo ago
        When you fix bugs, you don't edit history, you treat these as new features.
        dwattttt 5mo ago
        Correct. The comparable git workflow when you fix a bug is that the work goes on the branch of the feature the bug was in, and "main" is updated to use the new head of that branch.
  - jdiff 5mo ago
    Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.
    - kccqzy 5mo ago
      Of course I use jj every day. In fact it improves on mercurial by eliminating the need to run `hg evolve` because it just auto-evolves for you.
- Arainach 5mo ago
  git rebase -i drops you into a text editor where you have to manually copy, move, and edit lines, knowing what words mean what and manually type them each time. hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions. The two are as "equivalent" as i3 and KDE.
  - loeg 5mo ago
    I don't know what version of hg you're using, but the histedit I've used drops me into an identical text editing setup as git rebase -i. It includes a summary of what the verbs mean in a comment at the bottom.
    - Arainach 5mo ago
      Interesting. The curses interface for histedit has been around since 2019, and I had no idea it wasn't the default since it's dramatically nicer to work with: https://www.mercurial-scm.org/relnotes/4.9 https://www.mercurial-scm.org/relnotes/4.9
streetfighter64 5mo ago
> The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it. I don't know anything about mercurial, but is it really too much to ask of software engineers to understand a DAG (the only "internal data structure" in question)? About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.
- bsder 5mo ago
  > About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis. Nope. You are simply flat-out wrong. I have taught Mercurial to CEOs, secretaries, artists, craftsmen, etc. It just worked. They understood the mental model and happily used it to protect their stuff. The people I taught Mercurial to who worked with CNC machines in particular loved Mercurial as it protected them against changing some wonky setting in their CAD program that screwed everything up that they somehow couldn't figure out how to restore. Git I can barely even explain to CS majors. The fact that AI has so much training data and is so very, very good at explaining how to undo strange Git states is all the evidence you need for just how abjectly terribly the Git UX is. Jujutsu has proven that the underlying structure of Git is acceptable and that the issues really are all about the UX.
  - streetfighter64 5mo ago
    Well I can explain git to anybody who understands a DAG. And mercurial is also based on the exact same data structure. So yes it would be very surprising if you didn't consider it to be "acceptable". The fact that there's lots of training data out there on strange git states is proof of exactly my point. Git is popular and thus used by lots of people who don't know the first thing about the command line, let alone data structures. Had mercurial won you'd see exactly the same types of errors commonly appearing.
    - Arainach 5mo ago
homebrewer 5mo ago
I've never rm-rf'ed a git repo (why would you voluntarily remove the reflog?) while also being a very mid-tier developer. The types that do also tend to reboot machines every time something goes wrong instead of looking for the exact cause of the problem and fixing it once and for all; to screw around with SQL (move subqueries here or there, add and remove indexes at random) until it runs acceptably instead of building proper understanding of how their database works, and so on. At least judging by what I've seen. Not really something to be proud of.
jjav 5mo ago
> The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. Precisely this. I've been stuck using git since 2010 and to this day I have a large git-cheatsheet doc which I need to reference any time I need to do anything beyond the daily add+commit+push. The git commands make zero sense and are just about impossible to remember because they make no sense. In contrast, I've never felt a need for a cheatsheet doc for mercurial commands. > done rm -rf to start anew. Every single git user I've talked to has done that multiple times. Indeed! Of all the source control tools I've used, git is the only one where I regulary need to do a tarball of the src repo before doing any uncommon operations because there is a non-zero chance it'll go into some unrecoverable state and need to start over.

loeg 5mo ago

> How do you consider the UX "nearly identical" or "arguably worse"? The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better. > hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick. > I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times. I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.

kccqzy 5mo ago
> history is a stream of content-addressed commits Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`. Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.
- anal_reactor 5mo ago
  You mean "git tag"?
  - dwattttt 5mo ago
    If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git. EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy. A git-native workflow for this would be to have a sequence of branches you continue to update, where 'main' is those branches merged at all times.
    - anal_reactor 5mo ago
      When you fix bugs, you don't edit history, you treat these as new features.
      - dwattttt 5mo ago
        Correct. The comparable git workflow when you fix a bug is that the work goes on the branch of the feature the bug was in, and "main" is updated to use the new head of that branch.
- jdiff 5mo ago
  Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.
  - kccqzy 5mo ago
    Of course I use jj every day. In fact it improves on mercurial by eliminating the need to run `hg evolve` because it just auto-evolves for you.
Arainach 5mo ago
git rebase -i drops you into a text editor where you have to manually copy, move, and edit lines, knowing what words mean what and manually type them each time. hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions. The two are as "equivalent" as i3 and KDE.
- loeg 5mo ago
  I don't know what version of hg you're using, but the histedit I've used drops me into an identical text editing setup as git rebase -i. It includes a summary of what the verbs mean in a comment at the bottom.
  - Arainach 5mo ago
    Interesting. The curses interface for histedit has been around since 2019, and I had no idea it wasn't the default since it's dramatically nicer to work with: https://www.mercurial-scm.org/relnotes/4.9 https://www.mercurial-scm.org/relnotes/4.9

streetfighter64 5mo ago

> The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it. I don't know anything about mercurial, but is it really too much to ask of software engineers to understand a DAG (the only "internal data structure" in question)? About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.

bsder 5mo ago
> About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis. Nope. You are simply flat-out wrong. I have taught Mercurial to CEOs, secretaries, artists, craftsmen, etc. It just worked. They understood the mental model and happily used it to protect their stuff. The people I taught Mercurial to who worked with CNC machines in particular loved Mercurial as it protected them against changing some wonky setting in their CAD program that screwed everything up that they somehow couldn't figure out how to restore. Git I can barely even explain to CS majors. The fact that AI has so much training data and is so very, very good at explaining how to undo strange Git states is all the evidence you need for just how abjectly terribly the Git UX is. Jujutsu has proven that the underlying structure of Git is acceptable and that the issues really are all about the UX.
- streetfighter64 5mo ago
  Well I can explain git to anybody who understands a DAG. And mercurial is also based on the exact same data structure. So yes it would be very surprising if you didn't consider it to be "acceptable". The fact that there's lots of training data out there on strange git states is proof of exactly my point. Git is popular and thus used by lots of people who don't know the first thing about the command line, let alone data structures. Had mercurial won you'd see exactly the same types of errors commonly appearing.
  - Arainach 5mo ago

homebrewer 5mo ago

I've never rm-rf'ed a git repo (why would you voluntarily remove the reflog?) while also being a very mid-tier developer. The types that do also tend to reboot machines every time something goes wrong instead of looking for the exact cause of the problem and fixing it once and for all; to screw around with SQL (move subqueries here or there, add and remove indexes at random) until it runs acceptably instead of building proper understanding of how their database works, and so on. At least judging by what I've seen. Not really something to be proud of.

jjav 5mo ago

> The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. Precisely this. I've been stuck using git since 2010 and to this day I have a large git-cheatsheet doc which I need to reference any time I need to do anything beyond the daily add+commit+push. The git commands make zero sense and are just about impossible to remember because they make no sense. In contrast, I've never felt a need for a cheatsheet doc for mercurial commands. > done rm -rf to start anew. Every single git user I've talked to has done that multiple times. Indeed! Of all the source control tools I've used, git is the only one where I regulary need to do a tarball of the src repo before doing any uncommon operations because there is a non-zero chance it'll go into some unrecoverable state and need to start over.