5 ms·

I think you're agreeing? The superiority of Mercurial works against it, because while https://xkcd.com/1597/ https://xkcd.com/1597/ is entirely relatable, peop

I think you're agreeing? The superiority of Mercurial works against it, because while https://xkcd.com/1597/ https://xkcd.com/1597/ is entirely relatable, people are used to Git's specific flavour of incomprehensibility. It's normal, and the lore helps folk avoid the sharp edges most of the time.

The_Colonel 3y ago
No, the op made a much stronger case - basically that git is naturally more aligned with how people think and machines operate. Meanwhile, you're saying git is aligned with how people think merely because it got more mindshare early on.
- Ygg2 3y ago
  If that was the case, you wouldn't see thousands of git tutorials on the web. You wouldn't get pages like https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ getting on HN top page. And no, it's not how people think, nor how git shows it. Git shows changes as diffs, while it operates on compressed snapshots.
  - andrewaylett 3y ago
    There are, broadly speaking, two ways for a tool to become popular. The first is to be really good, and unfortunately that way doesn't work. The second is to already be popular, and that's where MySQL and Git came from. If git weren't written by Linus Torvalds, I'm sure it wouldn't have become nearly as popular. Git is, per the XKCD, a really neat graph system. There's not much that's special about that, though. Now it exists, we can write another just like it as a programming tutorial. The UI is better than it used to be, that's pretty much the best that can be said about it. But if you know the magic incantations you need to interact with it, and especially if you're using IDEs, it's really no worse than CVS. The biggest difference between git and MySQL is that the former is solid underpinnings but poor UI and the latter is poor underpinnings but easy to deploy. In both cases, the foibles are well enough known that most folk don't need to worry about them, and and most projects I've worked on would derive no benefit from switching to a different system that's only going to confuse people. I say this as someone who appreciates the graph, but has occasionally resorted to invoking plumbing directly because I can't work out which plumbing commands would do what I wanted.
  - pas 3y ago
    git stores diffs, but the usual operations are between commits, which resolve to a snapshot, yes. but there are operations that get the diffs (interactive rebase for example) so, git, in typical UNIX fashion, is a bit of this and that, a very useful collection of tools to work on a repository, under some allegorical unification umbrella.
    - j16sdiz 3y ago
      git don't really store diffs. It is a mix of both. Unpacked commits are snapshots.
      - andrewaylett 3y ago
        Layers of abstractions. From the outside, we see diffs (or checked out trees). Looking at the next layer in, every file in every commit is present in the DAG. Then the storage layer deduplicates and packs similar blobs as binary diffs. It's quite neat, the object DAG is the canonical representation, but we can optimise on one side for efficient storage and on the other side for our preferred visual representation. Both without particularly needing to worry about the canonical representation being an abstraction, as it's quite good at not being a leaky abstraction.

The_Colonel 3y ago

No, the op made a much stronger case - basically that git is naturally more aligned with how people think and machines operate. Meanwhile, you're saying git is aligned with how people think merely because it got more mindshare early on.

Ygg2 3y ago
If that was the case, you wouldn't see thousands of git tutorials on the web. You wouldn't get pages like https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ getting on HN top page. And no, it's not how people think, nor how git shows it. Git shows changes as diffs, while it operates on compressed snapshots.
- andrewaylett 3y ago
  There are, broadly speaking, two ways for a tool to become popular. The first is to be really good, and unfortunately that way doesn't work. The second is to already be popular, and that's where MySQL and Git came from. If git weren't written by Linus Torvalds, I'm sure it wouldn't have become nearly as popular. Git is, per the XKCD, a really neat graph system. There's not much that's special about that, though. Now it exists, we can write another just like it as a programming tutorial. The UI is better than it used to be, that's pretty much the best that can be said about it. But if you know the magic incantations you need to interact with it, and especially if you're using IDEs, it's really no worse than CVS. The biggest difference between git and MySQL is that the former is solid underpinnings but poor UI and the latter is poor underpinnings but easy to deploy. In both cases, the foibles are well enough known that most folk don't need to worry about them, and and most projects I've worked on would derive no benefit from switching to a different system that's only going to confuse people. I say this as someone who appreciates the graph, but has occasionally resorted to invoking plumbing directly because I can't work out which plumbing commands would do what I wanted.
- pas 3y ago
  git stores diffs, but the usual operations are between commits, which resolve to a snapshot, yes. but there are operations that get the diffs (interactive rebase for example) so, git, in typical UNIX fashion, is a bit of this and that, a very useful collection of tools to work on a repository, under some allegorical unification umbrella.
  - j16sdiz 3y ago
    git don't really store diffs. It is a mix of both. Unpacked commits are snapshots.
    - andrewaylett 3y ago
      Layers of abstractions. From the outside, we see diffs (or checked out trees). Looking at the next layer in, every file in every commit is present in the DAG. Then the storage layer deduplicates and packs similar blobs as binary diffs. It's quite neat, the object DAG is the canonical representation, but we can optimise on one side for efficient storage and on the other side for our preferred visual representation. Both without particularly needing to worry about the canonical representation being an abstraction, as it's quite good at not being a leaky abstraction.