4 ms·

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

xyzsparetimexyz 3mo ago
No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.
- palata 3mo ago
  So when someone tells you "understanding X helped me a lot", your answer is "no, it did not"? > It's not 1:1 at all. I don't see any mention of "1:1" in the parent.
  - jesse_ash 3mo ago
    > The UI of git directly reflects its internals Maybe?
  - debugnik 3mo ago
    They're replying to > The UI of git - for better or worse - directly reflects its internals.
    - palata 3mo ago
      > Half the git commands are low level, half are high level. Can't we say that the low level level commands reflect its internal? ...
      - twister2920 3mo ago
        of course we can, that's not what the original comment said though
hnfong 3mo ago
Same here. The git commands were confusing to me until I actually saw a Linus video on youtube explaining how the git data structures worked under the hood. It was dead simple, and one could easily mentally map the tools' functions onto how they operated on the data structures. Once I understood that, as you said, everything clicked into place. Somehow the "higher level abstractions" that git tries to do makes the things ever so more confusing.
- rmunn 3mo ago
  I've recommended https://learngitbranching.js.org/ https://learngitbranching.js.org/ to so many people. Something about seeing it visually, with the arrows pointing from child to parent, just clicks in the mind where a written explanation doesn't. (Not for everyone, of course: some people understand it quite well from the written explanation. But if your coworkers who don't grok Git are visual learners, https://learngitbranching.js.org/ https://learngitbranching.js.org/ might be the thing that helps them unlock a deeper understanding of what's going on with branches and HEAD and so on).
- psychoslave 3mo ago
  Can you point to this video please?
- thr0w__4w4y 3mo ago
  Not Linus, this is Randal Schwartz, but this might be the video you're thinking of? https://www.youtube.com/watch?v=8dhZ9BXQgc4 https://www.youtube.com/watch?v=8dhZ9BXQgc4
vasco 3mo ago
Mercurial had by far the best UX, never had to read anything to learn it. I just pretend that I'm using mercurial when using git and nuke local repo if I mess up. Been doing it for my whole career.
- black_knight 3mo ago
  I love darcs! Somehow its interface just vibes with me. It is interactive by default, and the commands like “record”, “rollback”, etc, are somehow intuitive. Darcs also tried to put more semantic content in the patches, like file operations or search replace parches. It is always satisfying to rename something, then merge in some work where someone used the old variable name in the meanwhile, and the merge would go through automatically applying the rename!
- yurishimo 3mo ago
  I've often found that many problems when working in teams can be traced back to `rebase`. I understand the benefits, but if you're already working on a team where history is not used in any serious way, then you cut out a lot of foot-guns by only using `merge`.
  - Hendrikto 3mo ago
    > if you're already working on a team where history is not used in any serious way Then you are doing it wrong. Sadly this is very common.
  - zwischenzug 3mo ago
    Except the "merge mess" footgun. I got into training people in Git (I now do it for O'Reilly) because I worked with 12 teams that merged _everything_ into sub-branches. The result was that the `git log --oneline` command resulted in screensful of just pipes. My initial training goal in training was getting my students to understand a rebase to avoid that mess.
    - psychoslave 3mo ago
      Can you point to your course in O'Reilly catalogue please?
Hendrikto 3mo ago
Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.
- hackrmn 3mo ago
  My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentially immutable), they don't venture farther than their confidence suggests, keeping it within the circle so to speak. The tragedy, if you ask me at least, is rather that they then start imposing the "keep it simple" culture onto everyone else, which frankly turns Git into what SVN and CVS were accomplishing before it, with all the drawbacks of those. This keeps 90% of the team satisfied 90% of the time because there's nothing wrong with strictly linear graphs and the pro's that are asked to produce these, can always squash-merge their intricate local development history before they push to Github (which some Git users also think is part of Git proper). Something about using Git in the aforementioned way just bugs me strongly. I admit it's a me problem, very likely, but lately I've also had to admit that it's not just that either. For instance, if I need to fix a bug I use `git blame` to find the commit where I have learned the bug originated. I do a `git checkout -b ... <commit>` to start working on a fix, creating a branch starting at the problematic commit. Already that is head and shoulders above what many people I work with do or know _what_ does (or why would one want to do that). I do it because it creates a _trail_, certainly more so than just committing on top of `master`, even with a good commit message. But my practice doesn't produce linear graphs, even as pushed to Github (which we have to use, for better and for worse) and shared with everyone. I then get people coming to me and complaining they can't merge and it becomes obvious they don't understand Git sufficiently to do anything else but `git reset --hard` or worse, `rm -rf * && git pull` and hope for the best. Not sure where I was going with this, something about why use Git when it's the new SVN with everything SVN had and none of what SVN didn't have...
Someone 3mo ago
> The UI of git - for better or worse - directly reflects its internals. I disagree. For example, we have, from “git checkout —help”: git checkout has two main modes: 1. Switch branches, with git checkout <branch> 2. Restore a different version of a file The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals? (And of course, there are many inconsistencies in the CLI that do not have to do with git internals that, even if you know what you want to do internally and which command to use, make figuring out the CLI incantation to do it harder than needed. That’s a different subject, but still contributes to “git is difficult to use”)
- inigyou 3mo ago
  I think they tried to fix this by adding new separate commands, right? git restore?
  - WorldMaker 3mo ago
    Yes, `git switch` and `git restore` are both marked stable now and have relatively clean UX. It can be worth reskilling out of `git checkout` habits and into these two separate commands.
- dundarious 3mo ago
  Switching branches involves: updating the field marking "current branch", and then updating the working copy to reflect the objects referenced. So for all trees/files, recursively restore wc to match the referenced blobs. Restoring a different version of a specific file/tree, involves recursively restoring wc of those files/trees to match the referenced blobs. So both are actually primarily the same task. Knowing a little about internals is exactly how it is easy to understand how the same code (and hence the verb "checkout") came to be used for both tasks. The reason it's still not great UI is that switching branch and restoring file arise in very different circumstances, and I want different guarantees and warnings and confirmations -- so using the same command still only makes sense when thinking very mechanistically.

xyzsparetimexyz 3mo ago

No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.

palata 3mo ago
So when someone tells you "understanding X helped me a lot", your answer is "no, it did not"? > It's not 1:1 at all. I don't see any mention of "1:1" in the parent.
- jesse_ash 3mo ago
  > The UI of git directly reflects its internals Maybe?
- debugnik 3mo ago
  They're replying to > The UI of git - for better or worse - directly reflects its internals.
  - palata 3mo ago
    > Half the git commands are low level, half are high level. Can't we say that the low level level commands reflect its internal? ...
    - twister2920 3mo ago
      of course we can, that's not what the original comment said though

hnfong 3mo ago

Same here. The git commands were confusing to me until I actually saw a Linus video on youtube explaining how the git data structures worked under the hood. It was dead simple, and one could easily mentally map the tools' functions onto how they operated on the data structures. Once I understood that, as you said, everything clicked into place. Somehow the "higher level abstractions" that git tries to do makes the things ever so more confusing.

rmunn 3mo ago
I've recommended https://learngitbranching.js.org/ https://learngitbranching.js.org/ to so many people. Something about seeing it visually, with the arrows pointing from child to parent, just clicks in the mind where a written explanation doesn't. (Not for everyone, of course: some people understand it quite well from the written explanation. But if your coworkers who don't grok Git are visual learners, https://learngitbranching.js.org/ https://learngitbranching.js.org/ might be the thing that helps them unlock a deeper understanding of what's going on with branches and HEAD and so on).
psychoslave 3mo ago
Can you point to this video please?
thr0w__4w4y 3mo ago
Not Linus, this is Randal Schwartz, but this might be the video you're thinking of? https://www.youtube.com/watch?v=8dhZ9BXQgc4 https://www.youtube.com/watch?v=8dhZ9BXQgc4

vasco 3mo ago

Mercurial had by far the best UX, never had to read anything to learn it. I just pretend that I'm using mercurial when using git and nuke local repo if I mess up. Been doing it for my whole career.

black_knight 3mo ago
I love darcs! Somehow its interface just vibes with me. It is interactive by default, and the commands like “record”, “rollback”, etc, are somehow intuitive. Darcs also tried to put more semantic content in the patches, like file operations or search replace parches. It is always satisfying to rename something, then merge in some work where someone used the old variable name in the meanwhile, and the merge would go through automatically applying the rename!
yurishimo 3mo ago
I've often found that many problems when working in teams can be traced back to `rebase`. I understand the benefits, but if you're already working on a team where history is not used in any serious way, then you cut out a lot of foot-guns by only using `merge`.
- Hendrikto 3mo ago
  > if you're already working on a team where history is not used in any serious way Then you are doing it wrong. Sadly this is very common.
- zwischenzug 3mo ago
  Except the "merge mess" footgun. I got into training people in Git (I now do it for O'Reilly) because I worked with 12 teams that merged _everything_ into sub-branches. The result was that the `git log --oneline` command resulted in screensful of just pipes. My initial training goal in training was getting my students to understand a rebase to avoid that mess.
  - psychoslave 3mo ago
    Can you point to your course in O'Reilly catalogue please?

Hendrikto 3mo ago

Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.

hackrmn 3mo ago
My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentially immutable), they don't venture farther than their confidence suggests, keeping it within the circle so to speak. The tragedy, if you ask me at least, is rather that they then start imposing the "keep it simple" culture onto everyone else, which frankly turns Git into what SVN and CVS were accomplishing before it, with all the drawbacks of those. This keeps 90% of the team satisfied 90% of the time because there's nothing wrong with strictly linear graphs and the pro's that are asked to produce these, can always squash-merge their intricate local development history before they push to Github (which some Git users also think is part of Git proper). Something about using Git in the aforementioned way just bugs me strongly. I admit it's a me problem, very likely, but lately I've also had to admit that it's not just that either. For instance, if I need to fix a bug I use `git blame` to find the commit where I have learned the bug originated. I do a `git checkout -b ... <commit>` to start working on a fix, creating a branch starting at the problematic commit. Already that is head and shoulders above what many people I work with do or know _what_ does (or why would one want to do that). I do it because it creates a _trail_, certainly more so than just committing on top of `master`, even with a good commit message. But my practice doesn't produce linear graphs, even as pushed to Github (which we have to use, for better and for worse) and shared with everyone. I then get people coming to me and complaining they can't merge and it becomes obvious they don't understand Git sufficiently to do anything else but `git reset --hard` or worse, `rm -rf * && git pull` and hope for the best. Not sure where I was going with this, something about why use Git when it's the new SVN with everything SVN had and none of what SVN didn't have...

Someone 3mo ago

> The UI of git - for better or worse - directly reflects its internals. I disagree. For example, we have, from “git checkout —help”: git checkout has two main modes: 1. Switch branches, with git checkout <branch> 2. Restore a different version of a file The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals? (And of course, there are many inconsistencies in the CLI that do not have to do with git internals that, even if you know what you want to do internally and which command to use, make figuring out the CLI incantation to do it harder than needed. That’s a different subject, but still contributes to “git is difficult to use”)

inigyou 3mo ago
I think they tried to fix this by adding new separate commands, right? git restore?
- WorldMaker 3mo ago
  Yes, `git switch` and `git restore` are both marked stable now and have relatively clean UX. It can be worth reskilling out of `git checkout` habits and into these two separate commands.
dundarious 3mo ago
Switching branches involves: updating the field marking "current branch", and then updating the working copy to reflect the objects referenced. So for all trees/files, recursively restore wc to match the referenced blobs. Restoring a different version of a specific file/tree, involves recursively restoring wc of those files/trees to match the referenced blobs. So both are actually primarily the same task. Knowing a little about internals is exactly how it is easy to understand how the same code (and hence the verb "checkout") came to be used for both tasks. The reason it's still not great UI is that switching branch and restoring file arise in very different circumstances, and I want different guarantees and warnings and confirmations -- so using the same command still only makes sense when thinking very mechanistically.