6 ms·

I read most of this long article, and I found it useful, but: It's unsurprising that people's mental model of git is incorrect. Git is not something people stu

I read most of this long article, and I found it useful, but: It's unsurprising that people's mental model of git is incorrect. Git is not something people study at a conceptual level, it's something they learn recipes for in order to work on some project. Recipes like "how do I save all this work I just did" and "oh shit, everything is hosed, please give me a magic spell I can paste into my terminal to fix it". I don't really blame people, since git itself does nothing to teach you how it works. Git it is the definition of something you have to deal with in order to do something more important to you. Some people want to dig deep and understand how the system works: it's nice to sit near that person and ask them for help sometimes. Saying "you should really understand more about git" is like saying "you should really study the tax code, it's important and it affects you whether you like it or not." True, but deeply irrelevant!

ilikepi 5y ago
In a literal sense, sure, git _the tool_ doesn't do much, though I think this is slowly improving as it evolves. For example, there is an experimental `git switch` command[1] under development to provide a simpler interface for changing branches. For me, the biggest leap in developing my own mental model was reading Scott Chacon's book Pro Git, and that is now available online for free on the official Git website[2]. [1]: http://git-scm.com/docs/git-switch http://git-scm.com/docs/git-switch [2]: http://git-scm.com/book/en/v2 http://git-scm.com/book/en/v2
deleted 5y ago
[deleted]
Certhas 5y ago
I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty repo or create one from an existing remote repo gl status - show status of the repo gl track - start tracking changes to files gl untrack - stop tracking changes to files gl diff - show changes to files gl commit - record changes in the local repo gl checkout - checkout committed versions of files gl history - show commit history gl branch - list, create, edit or delete branches gl switch - switch branches gl tag - list, create, or delete tags gl merge - merge the divergent changes of one branch onto another gl fuse - fuse the divergent changes of one branch onto another gl resolve - mark files with conflicts as resolved gl publish - publish commits upstream gl remote - list, create, edit or delete remotes To me this clearly demonstrates that the problem isn't that people aren't learning git, it's that git is bad to learn. Stash + Index + Working Tree isn't the right abstraction to present to people. Just say there is a working tree, and tracked and untracked files and snapshots. Done. Branches aren't particular commits but particular working trees on top of particular commits. Working on a feature and want to look at the main branch, but not ready to commit the changes yet? Well just switch to the main branch, then switch back and pick up where you started. No need to know about an additional data structure called the stash. Unfortunately this did not pick up enough steam. And because a lot of tools expose concepts from gits broken interface you have to learn the git interface anyway...
- zauguin 5y ago
  Having used `gitless` a while ago as my main interface I strongly disagree. Having a distinction between my working tree and things I'm actually considering to commit is a luxury you only really start to miss when it's gone. IMO gitless makes it way too easy commit too much. Also it's "feature" of keeping uncommitted changes local to the branch is just weird. If I want to make a branch specific change, I create a commit. This has the big advantage that it actually forces the user to add a message what the change is about, so if something else comes up I know what was going on when coming back to it later. It's not like this has to be a formal commit message, after all the commit can be dropped again later. Otherwise you end up being surprised by old experiments when switching to branches you haven't used in a while. If I just switch branches then the most likely reason for that is that I want to move the changes.
  - Certhas 5y ago
    Interesting. I haven't met many who have. Your two usecases basically never arose for me. If I switch back to a branch and there's random stuff there, then I can just revert easily. So it's an extra operation at a different time to get there. The other usecase for switching branches temporarily where it's one less command, is more important to me though. The crucial thing though is that both behaviours can be accessed easily but we are dealing with one less data store/stateful thing, because we don't need the stash. As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit. I wouldn't claim that gitless is a 100% complete git replacement for expert users. It just shows that git has way too much state exposed to users, and has confusing commands to make that state interact. Obviously we all learned git and use it successfully, so it's obviously not broken or anything, it's just worse than it could be (and the constant chorus of "it's so simple, just a DAG!" is a bit grating if you have to teach beginners regularly). The gitless authors did do some research with users that backs up the claim that this is conceptually easier to use: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf
    - 5y ago
cerved 5y ago
idk man, if you're a software engineer I think the onus is on you. There are plenty of great and free resources, like the pro git book. Every month there's a thread where a bunch of people come in and bemone how git is complicated blah blah. Every month lots of people point out that git is much easier to use if you just bother to conceptually learn about it's internals. it's like coming into a forum for accountants where people bitch about having to learn tax code. please...
tomxor 5y ago
> I don't really blame people, since git itself does nothing to teach you how it works. Git it is the definition of something you have to deal with in order to do something more important to you. Some people want to dig deep and understand how the system works: it's nice to sit near that person and ask them for help sometimes. The official git handbook, freely available on the official git-scm site is not terribly long, and explains the internals on a conceptual level quite well. I think the problem is most people learning git land on some wordpress site of someone trying to flog a condensed and uninsightful shortcut to getting started with git for ad clicks, which only involves a series of commands without explaining the effects of those commands - This, combined with peoples expectation that an SCM should take no thought whatsoever causes most people that use git on a day to day basis to not really understand it at all. Git needs to be introduced as powerful data structure, kind of like how SQL is not a DB, imagine someone explaining SQL without ever refering to the DB tables, rows and fields... only talking about git commits is like only talking about the result of a single query. You must understand the data structure to easily use the interface, otherwise the interface will be very confusing or you will be limited to "recipes"... after that you are just learning new variations on how to manipulate and navigate that structure (yes the graph), and from this perspective peoples complaints about the historical inconsistencies we have to put up with in git porcelain are moot.
- MathMonkeyMan 5y ago
  I was going to write a blog post conveying my mental model of what git is (having had one too many conversations along the lines of "no, git is not a ledger of diffs"). So, I started reading through <https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects> again to make sure I didn't have anything wrong. But now there's no point in writing a blog post. Maybe I'll write one that just links to <https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects>. It even has nice diagrams, which I think are essential for this kind of thing.
  - MathMonkeyMan 5y ago
    here: https://www.davidgoffredo.com/git https://www.davidgoffredo.com/git
cryptonector 5y ago
I use this when I want to teach someone Git: https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b3996549748d https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...
- tempodox 5y ago
  I find that a good introduction. “All operations on a repository involve adding commits and/or manipulating the name resolution table.” It may be simplified, but that statement alone, taken in context, is worth its weight in gold.
  - cryptonector 5y ago
    Thanks! It's simplified, but really, not that much.
    - ScreaminScott66 5y ago
      Simplified? Really? Heres a example only about one screen in.... "a bag of "commits" identified by a cryptographic hash value and which organize into trees via parent commit references in each commit" Say what?
OneEyedRobot 5y ago
>Some people want to dig deep and understand how the system works I'd say that's definitely the case but also a problem. Sophisticated users mixed with people who just want to do a few simple things is a bad combination. I seem to remember that ClearCase had the same issues.
dreamcompiler 5y ago
The tax code is a completely inscrutable mess but git's internal model is one of the most simple and elegant structures in modern computer science. It's just covered over with utterly stupid commands and terminology that obscures the beauty of the underlying architecture. I used to despise git because it was so hard to learn. Then as an exercise I started writing my own code to read and write its underlying files and it finally dawned on me how simple the whole thing was. Git's a very unusual piece of software; it's mind-bogglingly useful, the basic data structures and algorithms are perfectly matched to its job, and it has a UI that's a train wreck.

ilikepi 5y ago

In a literal sense, sure, git _the tool_ doesn't do much, though I think this is slowly improving as it evolves. For example, there is an experimental `git switch` command[1] under development to provide a simpler interface for changing branches. For me, the biggest leap in developing my own mental model was reading Scott Chacon's book Pro Git, and that is now available online for free on the official Git website[2]. [1]: http://git-scm.com/docs/git-switch http://git-scm.com/docs/git-switch [2]: http://git-scm.com/book/en/v2 http://git-scm.com/book/en/v2

deleted 5y ago

[deleted]

Certhas 5y ago

I think it's the other way around. The fact that git does not provide a clean analogous way to intuitively interact with it just demonstrates that the git interface is horribly broken. This is not essential complexity, it's just bad design that stuck. Take a look at https://gitless.com/ https://gitless.com/ If you just look at a summary of the commands, you will have an accurate mental model of what's going on: gl init - create an empty repo or create one from an existing remote repo gl status - show status of the repo gl track - start tracking changes to files gl untrack - stop tracking changes to files gl diff - show changes to files gl commit - record changes in the local repo gl checkout - checkout committed versions of files gl history - show commit history gl branch - list, create, edit or delete branches gl switch - switch branches gl tag - list, create, or delete tags gl merge - merge the divergent changes of one branch onto another gl fuse - fuse the divergent changes of one branch onto another gl resolve - mark files with conflicts as resolved gl publish - publish commits upstream gl remote - list, create, edit or delete remotes To me this clearly demonstrates that the problem isn't that people aren't learning git, it's that git is bad to learn. Stash + Index + Working Tree isn't the right abstraction to present to people. Just say there is a working tree, and tracked and untracked files and snapshots. Done. Branches aren't particular commits but particular working trees on top of particular commits. Working on a feature and want to look at the main branch, but not ready to commit the changes yet? Well just switch to the main branch, then switch back and pick up where you started. No need to know about an additional data structure called the stash. Unfortunately this did not pick up enough steam. And because a lot of tools expose concepts from gits broken interface you have to learn the git interface anyway...

zauguin 5y ago
Having used `gitless` a while ago as my main interface I strongly disagree. Having a distinction between my working tree and things I'm actually considering to commit is a luxury you only really start to miss when it's gone. IMO gitless makes it way too easy commit too much. Also it's "feature" of keeping uncommitted changes local to the branch is just weird. If I want to make a branch specific change, I create a commit. This has the big advantage that it actually forces the user to add a message what the change is about, so if something else comes up I know what was going on when coming back to it later. It's not like this has to be a formal commit message, after all the commit can be dropped again later. Otherwise you end up being surprised by old experiments when switching to branches you haven't used in a while. If I just switch branches then the most likely reason for that is that I want to move the changes.
- Certhas 5y ago
  Interesting. I haven't met many who have. Your two usecases basically never arose for me. If I switch back to a branch and there's random stuff there, then I can just revert easily. So it's an extra operation at a different time to get there. The other usecase for switching branches temporarily where it's one less command, is more important to me though. The crucial thing though is that both behaviours can be accessed easily but we are dealing with one less data store/stateful thing, because we don't need the stash. As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course. Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit. I wouldn't claim that gitless is a 100% complete git replacement for expert users. It just shows that git has way too much state exposed to users, and has confusing commands to make that state interact. Obviously we all learned git and use it successfully, so it's obviously not broken or anything, it's just worse than it could be (and the constant chorus of "it's so simple, just a DAG!" is a bit grating if you have to teach beginners regularly). The gitless authors did do some research with users that backs up the claim that this is conceptually easier to use: https://spderosso.github.io/oopsla16.pdf https://spderosso.github.io/oopsla16.pdf
  - 5y ago

cerved 5y ago

idk man, if you're a software engineer I think the onus is on you. There are plenty of great and free resources, like the pro git book. Every month there's a thread where a bunch of people come in and bemone how git is complicated blah blah. Every month lots of people point out that git is much easier to use if you just bother to conceptually learn about it's internals. it's like coming into a forum for accountants where people bitch about having to learn tax code. please...

tomxor 5y ago

> I don't really blame people, since git itself does nothing to teach you how it works. Git it is the definition of something you have to deal with in order to do something more important to you. Some people want to dig deep and understand how the system works: it's nice to sit near that person and ask them for help sometimes. The official git handbook, freely available on the official git-scm site is not terribly long, and explains the internals on a conceptual level quite well. I think the problem is most people learning git land on some wordpress site of someone trying to flog a condensed and uninsightful shortcut to getting started with git for ad clicks, which only involves a series of commands without explaining the effects of those commands - This, combined with peoples expectation that an SCM should take no thought whatsoever causes most people that use git on a day to day basis to not really understand it at all. Git needs to be introduced as powerful data structure, kind of like how SQL is not a DB, imagine someone explaining SQL without ever refering to the DB tables, rows and fields... only talking about git commits is like only talking about the result of a single query. You must understand the data structure to easily use the interface, otherwise the interface will be very confusing or you will be limited to "recipes"... after that you are just learning new variations on how to manipulate and navigate that structure (yes the graph), and from this perspective peoples complaints about the historical inconsistencies we have to put up with in git porcelain are moot.

MathMonkeyMan 5y ago
I was going to write a blog post conveying my mental model of what git is (having had one too many conversations along the lines of "no, git is not a ledger of diffs"). So, I started reading through <https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects> again to make sure I didn't have anything wrong. But now there's no point in writing a blog post. Maybe I'll write one that just links to <https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects>. It even has nice diagrams, which I think are essential for this kind of thing.
- MathMonkeyMan 5y ago
  here: https://www.davidgoffredo.com/git https://www.davidgoffredo.com/git

cryptonector 5y ago

I use this when I want to teach someone Git: https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b3996549748d https://gist.github.com/nicowilliams/a6e5c9131767364ce2f4b39...

tempodox 5y ago
I find that a good introduction. “All operations on a repository involve adding commits and/or manipulating the name resolution table.” It may be simplified, but that statement alone, taken in context, is worth its weight in gold.
- cryptonector 5y ago
  Thanks! It's simplified, but really, not that much.
  - ScreaminScott66 5y ago
    Simplified? Really? Heres a example only about one screen in.... "a bag of "commits" identified by a cryptographic hash value and which organize into trees via parent commit references in each commit" Say what?

OneEyedRobot 5y ago

>Some people want to dig deep and understand how the system works I'd say that's definitely the case but also a problem. Sophisticated users mixed with people who just want to do a few simple things is a bad combination. I seem to remember that ClearCase had the same issues.

dreamcompiler 5y ago

The tax code is a completely inscrutable mess but git's internal model is one of the most simple and elegant structures in modern computer science. It's just covered over with utterly stupid commands and terminology that obscures the beauty of the underlying architecture. I used to despise git because it was so hard to learn. Then as an exercise I started writing my own code to read and write its underlying files and it finally dawned on me how simple the whole thing was. Git's a very unusual piece of software; it's mind-bogglingly useful, the basic data structures and algorithms are perfectly matched to its job, and it has a UI that's a train wreck.