6 ms·

My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as

My mental model of a git repo is basically a bramble bush with labels on it. The bramble stems and branches are the commit history (which may join and well as split, unlike a bramble). The labels are stuck to particular bits of the bramble. Some labels are even stuck to other labels! You can move the labels around, and you can glue extra bits of bramble to the tips of what you have. You can even hack about with the bramble, but this is not recommended. Label moving often happens automatically, e.g. when 'growing' a bramble tip. It gets interesting when you compare two brambles (e.g. remote and local repos). You might determine that one bramble is identical to another, just with the labels moved. Or one bramble is the same as the other but with extra stems added. Or both brambles had a common ancestor bramble, but now they both have extra stems. Or perhaps they are completely irreconcilable. Better visualisation tooling would help.

bhrgunatha 4y ago
Learning the underlying model behind git is well worth the effort. For me watching Steve Smith's talk - Knowledge is Power: Getting out of Trouble by Understanding Git - was a lightbulb moment. Here's a 2019 presentation of that talk. https://www.youtube.com/watch?v=fHLcZGi3yMQ https://www.youtube.com/watch?v=fHLcZGi3yMQ
- tharkun__ 4y ago
  I think this is what can confuse people. We have to face the facts that not everyone will need or be able to grok all of what goes on in git and what makes the car go forward. We can all drive that car still! Take the recursive merging stuff around minute 39. Do I need to know why git's model for merging is so much better and how it works its magic? I don't think so. It's an implementation detail. Do I need to know how a gearbox works to drive stick shift? I have never thought of git as a bramble (tree worked fine for me :)) but the thing I always tell people about too is the labels part. What I think is enough for people to realize is that it's just like say SVN or CVS or any other source control mechanism in that there's a tree (bramble) of commits and then every commit can just be pointed to by a label. I can move those labels around any which way I want. Everything else follows from that on a surface level that is the only thing required to work with git in most situations, including some advanced ones. You don't need to know why certain operations in git are faster, better, have less conflicts or how they work internally. You just need to know what they do and when to apply them. I don't need to know why I can't make my car start or switch gears without pushing down the clutch. I just need to know when to push the clutch, i.e. if I want to start the car, push it. When I want to switch gears push it (well, mostly, on cars you want to last a while still lol). Of course some people won't even be able to learn how to drive stick shift and can only ever drive automatic.
  - leephillips 4y ago
    To a large extent, yes. But when you find yourself stopped at a red light on a steep upgrade, and some idiot behind you decides to wait for the light three inches from your back bumper, things will go better when the light turns green if you have a decent mental model of the physical mechanism of the clutch. Sometimes you want to let those abstractions leak a bit.
    - tomohawk 4y ago
      They'll go even better for you if you just have good skill with the clutch - regardless of how it works or not.
      - macintux 4y ago
        Agreed, I’ve only recently learned (at a high level) how a clutch works, and it has zero impact on how I use it on the street. Even off-road, I really only need to know to not ride it all the time.
    - tharkun__ 4y ago
      Actually you don't need a mental model of the clutch at all for that. You just need to know how to handle steep inclines. There's a technique for that. All you need to know for that is the fact that on a steep incline you will go back a bit until your clutch has a chance to get you moving forward against the hill and that in this case you need to apply that technique. Like knowing when to use rebase, when to use cherry-pick etc. Now why you will roll back on the steep hill is not something a normal operator of a car needs to understand. Neither the clutch part nor the gravity one actually. Also, if he's literally 3 inches, I would say the best approach is to slowly ease off the brakes until you actually touch the other car but do it so slowly that it's not an impact. All without even pushing the clutch. Then you don't even need to use the brake while pushing the gas pedal trick, because the guy behind you is your brake pedal ;)
    - CobaltFire 4y ago
      For a group of people supposedly primarily in the SV area this is a scary comment thread. I learned to drive stick in the Bay Area and the way everyone I know there drives stick on an incline is to use the parking brake with a second hand when letting off the brake and letting out the clutch. Now, when you get good you can stop doing this for most, but for really steep streets (I now live in San Diego and we have a couple; Laurel being one) it’s still an excellent skill to have.
- stjohnswarts 4y ago
  thanks, I'll be watching this. seems like I get myself in trouble every couple of months and have to zip up a directory, do a fresh checkout and overlay it. Seems sometimes something gets lost and it will refuse to push to origin on a branch that I've had checked out for a while. yet if I do a fresh checkout (and losing a bit of history as I like to commit locally a lot and squash just before I'm ready to push to git repo.
layer8 4y ago
Conceptualizing a commit graph with branch/tag labels is the easy part. What gets messy is operations regarding remote vs. local (as you mention) and regarding the various local state one may have (working directory, index/staging). Then there’s also the issues that arise with merging, but you have those with every VCS.
- neandrake 4y ago
  I love mercurial’s solution of having phases for commits. Anything you created locally is Draft phase and can be mutated without “force”. Anything which was pulled or pushed is automatically marked as Public and is not easily mutated. Visualizing the commit graph also colors commits based on phase making it really easy to get a grasp of what’s going on. Is there an extension or something for Git to have similar behavior to this?
  - layer8 4y ago
    Instead of using colors, a visualization that can be combined with branch colors would be nice. For example using bold for remote (“public”) commits, or dashed lines for local (“draft”) commits.
kps 4y ago
My mental model of a git repo is basically a stack of backup tapes with sticky notes on them that say “this is tape #2983 and it's almost the same as tape #2429, except that I fixed a typo.” Things like `git log` and common workflows make you think “this is change #2983, where I fixed a typo”, and that's where the trouble starts.
- duped 4y ago
  It's an organizational and personal thing, but you really have to get in the habit of treating commits as single diffs to the codebase and not the equivalent of ctrl + s in your editor. I try and make a habit of squashing my commits so that git log is a narrative of development and each commit is a page number, not a sticky note.
agumonkey 4y ago
Also toying at the commit sequence layer is fun (rebase) and should be expanded.

bhrgunatha 4y ago

Learning the underlying model behind git is well worth the effort. For me watching Steve Smith's talk - Knowledge is Power: Getting out of Trouble by Understanding Git - was a lightbulb moment. Here's a 2019 presentation of that talk. https://www.youtube.com/watch?v=fHLcZGi3yMQ https://www.youtube.com/watch?v=fHLcZGi3yMQ

tharkun__ 4y ago
I think this is what can confuse people. We have to face the facts that not everyone will need or be able to grok all of what goes on in git and what makes the car go forward. We can all drive that car still! Take the recursive merging stuff around minute 39. Do I need to know why git's model for merging is so much better and how it works its magic? I don't think so. It's an implementation detail. Do I need to know how a gearbox works to drive stick shift? I have never thought of git as a bramble (tree worked fine for me :)) but the thing I always tell people about too is the labels part. What I think is enough for people to realize is that it's just like say SVN or CVS or any other source control mechanism in that there's a tree (bramble) of commits and then every commit can just be pointed to by a label. I can move those labels around any which way I want. Everything else follows from that on a surface level that is the only thing required to work with git in most situations, including some advanced ones. You don't need to know why certain operations in git are faster, better, have less conflicts or how they work internally. You just need to know what they do and when to apply them. I don't need to know why I can't make my car start or switch gears without pushing down the clutch. I just need to know when to push the clutch, i.e. if I want to start the car, push it. When I want to switch gears push it (well, mostly, on cars you want to last a while still lol). Of course some people won't even be able to learn how to drive stick shift and can only ever drive automatic.
- leephillips 4y ago
  To a large extent, yes. But when you find yourself stopped at a red light on a steep upgrade, and some idiot behind you decides to wait for the light three inches from your back bumper, things will go better when the light turns green if you have a decent mental model of the physical mechanism of the clutch. Sometimes you want to let those abstractions leak a bit.
  - tomohawk 4y ago
    They'll go even better for you if you just have good skill with the clutch - regardless of how it works or not.
    - macintux 4y ago
      Agreed, I’ve only recently learned (at a high level) how a clutch works, and it has zero impact on how I use it on the street. Even off-road, I really only need to know to not ride it all the time.
  - tharkun__ 4y ago
    Actually you don't need a mental model of the clutch at all for that. You just need to know how to handle steep inclines. There's a technique for that. All you need to know for that is the fact that on a steep incline you will go back a bit until your clutch has a chance to get you moving forward against the hill and that in this case you need to apply that technique. Like knowing when to use rebase, when to use cherry-pick etc. Now why you will roll back on the steep hill is not something a normal operator of a car needs to understand. Neither the clutch part nor the gravity one actually. Also, if he's literally 3 inches, I would say the best approach is to slowly ease off the brakes until you actually touch the other car but do it so slowly that it's not an impact. All without even pushing the clutch. Then you don't even need to use the brake while pushing the gas pedal trick, because the guy behind you is your brake pedal ;)
  - CobaltFire 4y ago
    For a group of people supposedly primarily in the SV area this is a scary comment thread. I learned to drive stick in the Bay Area and the way everyone I know there drives stick on an incline is to use the parking brake with a second hand when letting off the brake and letting out the clutch. Now, when you get good you can stop doing this for most, but for really steep streets (I now live in San Diego and we have a couple; Laurel being one) it’s still an excellent skill to have.
stjohnswarts 4y ago
thanks, I'll be watching this. seems like I get myself in trouble every couple of months and have to zip up a directory, do a fresh checkout and overlay it. Seems sometimes something gets lost and it will refuse to push to origin on a branch that I've had checked out for a while. yet if I do a fresh checkout (and losing a bit of history as I like to commit locally a lot and squash just before I'm ready to push to git repo.

layer8 4y ago

Conceptualizing a commit graph with branch/tag labels is the easy part. What gets messy is operations regarding remote vs. local (as you mention) and regarding the various local state one may have (working directory, index/staging). Then there’s also the issues that arise with merging, but you have those with every VCS.

neandrake 4y ago
I love mercurial’s solution of having phases for commits. Anything you created locally is Draft phase and can be mutated without “force”. Anything which was pulled or pushed is automatically marked as Public and is not easily mutated. Visualizing the commit graph also colors commits based on phase making it really easy to get a grasp of what’s going on. Is there an extension or something for Git to have similar behavior to this?
- layer8 4y ago
  Instead of using colors, a visualization that can be combined with branch colors would be nice. For example using bold for remote (“public”) commits, or dashed lines for local (“draft”) commits.

kps 4y ago

My mental model of a git repo is basically a stack of backup tapes with sticky notes on them that say “this is tape #2983 and it's almost the same as tape #2429, except that I fixed a typo.” Things like `git log` and common workflows make you think “this is change #2983, where I fixed a typo”, and that's where the trouble starts.

duped 4y ago
It's an organizational and personal thing, but you really have to get in the habit of treating commits as single diffs to the codebase and not the equivalent of ctrl + s in your editor. I try and make a habit of squashing my commits so that git log is a narrative of development and each commit is a page number, not a sticky note.

agumonkey 4y ago

Also toying at the commit sequence layer is fun (rebase) and should be expanded.