4 ms·

> 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 exp

> 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
    Mercurial doesn't require understanding a DAG. You can get by with `hg next`, `hg prev`, and `hg rebase -s <from> -d <to>` to move entire chains of commits around. Commands with obvious names that allow moving around without understanding chains of dependencies. No weird states where you checkout an old commit but random files from where you just were are left in the directory tree for you to deal with. No difference between `checkout`, `reset --soft`, and `reset --hard` to remember. No detached head states. And no, `HEAD~1` is not a replacement for `prev`. One is a shortening of "previous", one requires you to remember a magic constant based on knowledge of the DAG. As for `hg next`, the various responses here should show how clear, obvious, and intuitive the git UI is: https://stackoverflow.com/questions/6759791/how-do-i-move-forward-and-backward-between-commits-in-git https://stackoverflow.com/questions/6759791/how-do-i-move-fo...
    - loeg 5mo ago
      I disagree that Mercurial users can use `hg rebase -s ... -d ...` without understanding a DAG. The mechanism is only meaningful if you understand the structure of the commit graph.
    - streetfighter64 5mo ago
      Look, I'm not commenting on which system has better named commands. My main points are 1) A DAG is not a difficult concept to understand (despite the "scary" name). If you can understand package dependencies or a manufacturing process you already understand it. 2) Learning git without knowing about the DAG, i.e. knowing what a commit even is, is counterproductive. It's like learning to drive a manual car without knowing what the clutch does. Sure you could probably teach someone that way, but why would you? What's the benefit to learning mercurial without understanding what a rebase actually does?
  - com2kid 5mo ago
    If I spend a couple hours reading I can understand how git works, but I'm going to forget an hour later because it is so damn complicated with all the different details that my brain flushes it's cache to make room for something with less violently confusing edge cases.
- happymellon 5mo ago
  > Git I can barely even explain to CS majors. Considering the number of kids that I've managed to understand git, I think this might be a teaching issue.

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
  Mercurial doesn't require understanding a DAG. You can get by with `hg next`, `hg prev`, and `hg rebase -s <from> -d <to>` to move entire chains of commits around. Commands with obvious names that allow moving around without understanding chains of dependencies. No weird states where you checkout an old commit but random files from where you just were are left in the directory tree for you to deal with. No difference between `checkout`, `reset --soft`, and `reset --hard` to remember. No detached head states. And no, `HEAD~1` is not a replacement for `prev`. One is a shortening of "previous", one requires you to remember a magic constant based on knowledge of the DAG. As for `hg next`, the various responses here should show how clear, obvious, and intuitive the git UI is: https://stackoverflow.com/questions/6759791/how-do-i-move-forward-and-backward-between-commits-in-git https://stackoverflow.com/questions/6759791/how-do-i-move-fo...
  - loeg 5mo ago
    I disagree that Mercurial users can use `hg rebase -s ... -d ...` without understanding a DAG. The mechanism is only meaningful if you understand the structure of the commit graph.
  - streetfighter64 5mo ago
    Look, I'm not commenting on which system has better named commands. My main points are 1) A DAG is not a difficult concept to understand (despite the "scary" name). If you can understand package dependencies or a manufacturing process you already understand it. 2) Learning git without knowing about the DAG, i.e. knowing what a commit even is, is counterproductive. It's like learning to drive a manual car without knowing what the clutch does. Sure you could probably teach someone that way, but why would you? What's the benefit to learning mercurial without understanding what a rebase actually does?
- com2kid 5mo ago
  If I spend a couple hours reading I can understand how git works, but I'm going to forget an hour later because it is so damn complicated with all the different details that my brain flushes it's cache to make room for something with less violently confusing edge cases.
happymellon 5mo ago
> Git I can barely even explain to CS majors. Considering the number of kids that I've managed to understand git, I think this might be a teaching issue.