4 ms·

Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: b

Git has a terrible UI from a learning point of view. You can't learn Git by using its commands. You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Because Git is really just a brilliantly simple data structure manipulated by dozens of ad-hoc commands.

LtWorf 4y ago
How to waste a week without learning anything useful about actually using git :D At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.
bilekas 4y ago
> You can't learn Git by using its commands. From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools. Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.
- parasti 4y ago
  > Once you know what is happening, even those crazy states you can find yourself in really are not that hard. I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
  - bilekas 4y ago
    > But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense. You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.
globular-toast 4y ago
There are a couple of problems with this in my experience. People who have done computer science or systems/OS programming in a lower level language like C are really comfortable with concepts like pointers/references/links, objects, trees etc. But there are loads of programmers who don't speak this language at all. When I try to explain that almost everything is immutable and append-only and they are only mutating a single reference called HEAD it just doesn't make sense. The other thing is, like you say, git itself is a terrible way to learn these concepts. A command line interface is great for expressing operations, but the state, before and after, is basically invisible. I think this might be especially hard for more visual people. When I was learning data structures drawing them out and "seeing" the structure was vitally important and I know it's not just me because computer science books are filled with pictures. I really want there to be a GUI I can recommend people to use for git, but I'm not aware of a good one. I use magit which helps a lot, but I can't recommend that to most people. All the other GUIs I've seen are just about doing command line stuff with a mouse.
hardware2win 4y ago
Is there any other soft where ppl do seriously advise newbies to learn its internals? Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass" Imagine having to read excel's or windows code in order to use it consciously, lol.
- omnicognate 4y ago
  You don't need to learn its internals or read its code. You do need to learn what it does. This is not unreasonable, and is not the reason its interface is a mess.
  - hardware2win 4y ago
    Previous poster literally writes about implementation details. >You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal
    - carapace 4y ago
      Blobs, trees, commits, refs, and index are not "internals" or "implementation details", they are the domain. It's like how for a word processor the domain is text, et. al., or for e.g. Inkscape the domain is SVG. Git has two levels, called "plumbing" and "porcelain" (I think.) The "plumbing" (blobs, trees, commits, refs, and index) is elegant and easy to understand and use. The "porcelain" is where everybody gets bogged down. I'll omit my own opinion (low) and just say that most of the problems people have with git seem to be related to trying to do complicated things with the crummy UX porcelain. And that seems to be because they learned the porcelain but not the plumbing. So what you're hearing is people advising people to learn the plumbing (as a side effect the porcelain becomes less unbearable.) In fact, if you know the plumbing you can write your own porcelain, and it's not hard and the code is brief because git is actually elegant and easy to understand and use.
    - elsjaako 4y ago

LtWorf 4y ago

How to waste a week without learning anything useful about actually using git :D At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.

bilekas 4y ago

> You can't learn Git by using its commands. From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools. Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.

parasti 4y ago
> Once you know what is happening, even those crazy states you can find yourself in really are not that hard. I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
- bilekas 4y ago
  > But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense. You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.

globular-toast 4y ago

There are a couple of problems with this in my experience. People who have done computer science or systems/OS programming in a lower level language like C are really comfortable with concepts like pointers/references/links, objects, trees etc. But there are loads of programmers who don't speak this language at all. When I try to explain that almost everything is immutable and append-only and they are only mutating a single reference called HEAD it just doesn't make sense. The other thing is, like you say, git itself is a terrible way to learn these concepts. A command line interface is great for expressing operations, but the state, before and after, is basically invisible. I think this might be especially hard for more visual people. When I was learning data structures drawing them out and "seeing" the structure was vitally important and I know it's not just me because computer science books are filled with pictures. I really want there to be a GUI I can recommend people to use for git, but I'm not aware of a good one. I use magit which helps a lot, but I can't recommend that to most people. All the other GUIs I've seen are just about doing command line stuff with a mouse.

hardware2win 4y ago

Is there any other soft where ppl do seriously advise newbies to learn its internals? Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass" Imagine having to read excel's or windows code in order to use it consciously, lol.

omnicognate 4y ago
You don't need to learn its internals or read its code. You do need to learn what it does. This is not unreasonable, and is not the reason its interface is a mess.
- hardware2win 4y ago
  Previous poster literally writes about implementation details. >You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal
  - carapace 4y ago
    Blobs, trees, commits, refs, and index are not "internals" or "implementation details", they are the domain. It's like how for a word processor the domain is text, et. al., or for e.g. Inkscape the domain is SVG. Git has two levels, called "plumbing" and "porcelain" (I think.) The "plumbing" (blobs, trees, commits, refs, and index) is elegant and easy to understand and use. The "porcelain" is where everybody gets bogged down. I'll omit my own opinion (low) and just say that most of the problems people have with git seem to be related to trying to do complicated things with the crummy UX porcelain. And that seems to be because they learned the porcelain but not the plumbing. So what you're hearing is people advising people to learn the plumbing (as a side effect the porcelain becomes less unbearable.) In fact, if you know the plumbing you can write your own porcelain, and it's not hard and the code is brief because git is actually elegant and easy to understand and use.
  - elsjaako 4y ago