5 ms·

> is “how Git implements it” really the right way to explain it? Of course not, and nowhere outside of software engineering will you find such widespread confu

by p-e-w 3y ago

> is “how Git implements it” really the right way to explain it? Of course not, and nowhere outside of software engineering will you find such widespread confusion between concepts and their implementation. Do we think of pressing the gas pedal in a car as "accelerate", or as "regulate the intake manifold"? Commits are one of the most high-level concepts in Git. If an explanation for them resorts to implementation details, it's a bad explanation.

charcircuit 3y ago
I think if it as "regulate the intake manifold" or revving the engine because I feel it makes more sense. I don't really understand the relationship between how much you push the pedal and how much acceleration it produces. I've given up on trying to understand that, so I don't think of it as acceleration.
- ikari_pl 3y ago
  I'd argue that you intuitively do. When driving, you know when to press it lightly, and when more, as well as what the expected result will be. That would mean, I think, that the implementation details are irrelevant, because it's abstracted well enough to serve its purpose - and it's so easy that usually the FIRST driving lesson takes you into actual traffic (at least in Poland).
  - charcircuit 3y ago
    I disagree. I see it as a control system. I have a target acceleration and I have to change the input to the system to hone in on my target acceleration. I don't intuitively know how to accelerate at 10 mph / s. But by watching a guage I could be the control system that tries to do so.
kqr 3y ago
Or even worse -- regulating the manifold pressute. A resting gas pedal means the engine is suctioning a vacuum in the manifold, whereas a fully depressed pedal means the manifold is restored to atmospheric pressure!
- MadnessASAP 3y ago
  > restored to atmospheric pressure! Cries in sad turbo noises
rtpg 3y ago
It's funny you mention that, because Design of Everyday Things has a whole part about how people abstracting away the implementation leads to people having extremely wrong ideas about how things work. I think abstraction is good in theory, but at the end of the day the implementation is what is happening. The classic thing of people relying on undocumented behavior, etc etc. What good is a conceptual representation that doesn't actually align with what happens? It's not like the gas pedal being pressed down is actually what makes a car accelerate, after all! Whenever you're dealing with something _not_ working as expected, those who know the implementation are going to be in a much more comfortable position in general IMO.
- strogonoff 3y ago
  Not understanding how things work can result in very suboptimal decisions, and throttle control is a good example. Even in a good old ICE car the throttle is not as straightforward as “more ‘gas’ equals more acceleration” (depending on many factors, such as road surface conditions, it can also make you go slower or stop completely). An airplane would take it to a whole new level. What throttle does is dependent on fuel mixture, air density at your altitude, the configuration of controls—in fact, it’s probably much easier to enumerate the limited scenarios in which throttle actually makes you go faster as opposed to straight up crash. There can be made an argument that smart systems could/should, with their layers of abstraction, maintain an illusion of ‘gas’ = acceleration, and that human should not have to know anything else; but would you trust your life to such an arrangement? There can be an argument that stakes are high in case of air travel, and low in case of VCS; but that falls apart if you consider source code managed in a VCS can indeed power a life-critical system, and if not knowing well enough how the VCS works can lead to development overhead and eventually bugs in that system, then human cost is real.
  - p-e-w 3y ago
    The purpose of the VCS is to abstract away how its concepts are implemented. It should be possible to replace the standard Git implementation with any other that provides the same external interface without the user being affected, or even noticing it. If that isn't possible, the problem lies with Git, not with users "not understanding" it.
samus 3y ago
In German (and curiosly also in Chinese) "adding" or "giving gas" is the common idiom for accellerating. Also sometimes in general for putting in more effort. Git actually presents a very simple view to the user: repository states across time. These states can be compared to each other.
- tsimionescu 3y ago
  > Git actually presents a very simple view to the user: repository states across time. That doesn't explain commands like rebase or cherry-pick or even patch. The diff algorithm that generates diffs based on history is very much integral to git, even if it is configurable. There are plenty of git commands that assume you can meaningfully transform a commit into a diff from its parent(s). So commits are sometimes snapshots sometimes diffs, depending on the tool you're using to interact with them.
  - samus 3y ago
    That's true. However, that's implicit in the way these commands are defined. It has to be that way to make working with Git efficient, which is optimized for common use cases. For example, to cherry-pick a single commit.
kaelinl 3y ago
People who must diagnose, modify, optimize, or establish procedures for operating the car think of it in the context of the system. Meanwhile, people who strictly want to move forward think of it as the accelerator. Likewise for engineering tools. If you'd like to use a simple abstraction as your mental model, you'll be able to operate the tool in the basic sense without issue. But as engineers, when something goes wrong with our tools we often don't immediately bring it into a mechanic. We need our tools to do very specific things, and we must understand what they did each time we perform an operation. We establish workflows that build on top of the tools and depend on the tool matching our precise expectations of its behavior. In essence, we are the mechanic for our own car. And of course, our needs are much more diverse than "make car go forward". So inevitably, we run into trouble more often. What user-facing function of a car is as precise, powerful or intricate as a textual merge or reconciling two diverged work histories? There are many ways those operations can be done, and questions the user must answer about their desired result.
- xboxnolifes 3y ago
  Based on your first paragraph, it's not all engineers who need an indepth understanding of git. Only git engineers.
codeflo 3y ago
> Do we think of pressing the gas pedal in a car as "accelerate", or as "regulate the intake manifold"? I'm just curious -- which of the two do you think is the correct mental model to safely drive a car? If you think its the former, my guess is you've never driven where there are mountains and/or never driven manual.
- p-e-w 3y ago
  The correct way to safely drive a car is intuition – not a "mental model" of anything. That's why experienced drivers drive so much more safely than novice ones. It's certainly not because in the meantime, they somehow learned how the throttle works internally. The same basic lesson applies to software. The best design is the one that lends itself most to human intuition. Because when saving a photo from an image editor, users sure as hell aren't thinking "now an inode is created with this and that metadata".
  - codeflo 3y ago
    Intuition implies a mental model, just not a conscious one.
- kelnos 3y ago
  I've driven in mountains (I'm actually in the mountains, with snow on the ground, even, right now) and for 15 years drove manual (I sometimes miss it, but mostly do not, in the same way that I run Debian now and can't be bothered to run a distro like Gentoo anymore), but I literally never thought of pressing the gas pedal as "regulate the intake manifold". I honestly don't even know what an intake manifold is, though I'm sure if I cared enough, Wikipedia would tell me. Certainly my understanding of it is a bit more nuanced than simply "accelerate", but ultimately.... "press pedal harder, car moves faster" is... fine? Sure, you have to consider road conditions and (if driving manual) your current gear, speed, RPMs, etc., but... I dunno, I still think "press pedal harder, car moves faster" is a useful mental model to have, to some non-zero level of approximation. Put another way: if I were to think of all the details of what the accelerator of a car actually does under the hood every time I pressed it, and consider the implications of it and allow that to inform how I press the accelerator, I would have precious little time to actually drive the car... like, the things that actually matter, like steering and staying on the road and avoiding other cars and people and whatnot. When I press the accelerator, I think about the effect it's going to have on the car. And I have a good idea of what effect it's going to have based on my experience driving that car (or any car, really). Not based on any knowledge -- knowledge that I lack! -- of what pressing the accelerator actually does.
usr1106 3y ago
> is “how Git implements it” really the right way to explain it? >> Of course not, As long as the user is a software developer I would disagree. If the developer cannot understand the implementation concept style of explanation, I don't want to use or review their code either. I am saying implementation concepts as object storage, branches being pointers to objects etc. Of course implementation details and optimizations like packfiles don't matter. Every user-friendly explanation will have its limits once we get merges, rebases etc. For software developers it is important that their mental models don't hit such limits. If the user is not a software developer you have a point.
nonameiguess 3y ago
Both need to be known by someone but I still think this is a useful insight. The implementation details are key if you have to troubleshoot and want to know your tools at a deep level. It's also useful for anyone trying to implement their own version of a product with the same objective from scratch. You want to know the history of how something has been implemented by other attempts. That is a key priniciple of engineering in general. But ultimately, the implementation should involve choices and the possibility of change. git commit is saying the current state of the staged tree should be recoverable by any future user of this same repo. There are many possible ways to achieve this goal and how git happens to currently do it is worth knowing for some people. It's certainly been fascinating to read the months of output Julia Evans has put into this git plumbing exploration series. But I don't think it's critical for every single user of git to understand at this level of detail exactly how git works, and in principle, the developers of git should be able to change this without changing the semantics of what it means to commit in any user-facing way.

by p-e-w 3y ago

charcircuit 3y ago

I think if it as "regulate the intake manifold" or revving the engine because I feel it makes more sense. I don't really understand the relationship between how much you push the pedal and how much acceleration it produces. I've given up on trying to understand that, so I don't think of it as acceleration.

ikari_pl 3y ago
I'd argue that you intuitively do. When driving, you know when to press it lightly, and when more, as well as what the expected result will be. That would mean, I think, that the implementation details are irrelevant, because it's abstracted well enough to serve its purpose - and it's so easy that usually the FIRST driving lesson takes you into actual traffic (at least in Poland).
- charcircuit 3y ago
  I disagree. I see it as a control system. I have a target acceleration and I have to change the input to the system to hone in on my target acceleration. I don't intuitively know how to accelerate at 10 mph / s. But by watching a guage I could be the control system that tries to do so.

kqr 3y ago

Or even worse -- regulating the manifold pressute. A resting gas pedal means the engine is suctioning a vacuum in the manifold, whereas a fully depressed pedal means the manifold is restored to atmospheric pressure!

MadnessASAP 3y ago
> restored to atmospheric pressure! Cries in sad turbo noises

rtpg 3y ago

It's funny you mention that, because Design of Everyday Things has a whole part about how people abstracting away the implementation leads to people having extremely wrong ideas about how things work. I think abstraction is good in theory, but at the end of the day the implementation is what is happening. The classic thing of people relying on undocumented behavior, etc etc. What good is a conceptual representation that doesn't actually align with what happens? It's not like the gas pedal being pressed down is actually what makes a car accelerate, after all! Whenever you're dealing with something _not_ working as expected, those who know the implementation are going to be in a much more comfortable position in general IMO.

strogonoff 3y ago
Not understanding how things work can result in very suboptimal decisions, and throttle control is a good example. Even in a good old ICE car the throttle is not as straightforward as “more ‘gas’ equals more acceleration” (depending on many factors, such as road surface conditions, it can also make you go slower or stop completely). An airplane would take it to a whole new level. What throttle does is dependent on fuel mixture, air density at your altitude, the configuration of controls—in fact, it’s probably much easier to enumerate the limited scenarios in which throttle actually makes you go faster as opposed to straight up crash. There can be made an argument that smart systems could/should, with their layers of abstraction, maintain an illusion of ‘gas’ = acceleration, and that human should not have to know anything else; but would you trust your life to such an arrangement? There can be an argument that stakes are high in case of air travel, and low in case of VCS; but that falls apart if you consider source code managed in a VCS can indeed power a life-critical system, and if not knowing well enough how the VCS works can lead to development overhead and eventually bugs in that system, then human cost is real.
- p-e-w 3y ago
  The purpose of the VCS is to abstract away how its concepts are implemented. It should be possible to replace the standard Git implementation with any other that provides the same external interface without the user being affected, or even noticing it. If that isn't possible, the problem lies with Git, not with users "not understanding" it.

samus 3y ago

In German (and curiosly also in Chinese) "adding" or "giving gas" is the common idiom for accellerating. Also sometimes in general for putting in more effort. Git actually presents a very simple view to the user: repository states across time. These states can be compared to each other.

tsimionescu 3y ago
> Git actually presents a very simple view to the user: repository states across time. That doesn't explain commands like rebase or cherry-pick or even patch. The diff algorithm that generates diffs based on history is very much integral to git, even if it is configurable. There are plenty of git commands that assume you can meaningfully transform a commit into a diff from its parent(s). So commits are sometimes snapshots sometimes diffs, depending on the tool you're using to interact with them.
- samus 3y ago
  That's true. However, that's implicit in the way these commands are defined. It has to be that way to make working with Git efficient, which is optimized for common use cases. For example, to cherry-pick a single commit.

kaelinl 3y ago

People who must diagnose, modify, optimize, or establish procedures for operating the car think of it in the context of the system. Meanwhile, people who strictly want to move forward think of it as the accelerator. Likewise for engineering tools. If you'd like to use a simple abstraction as your mental model, you'll be able to operate the tool in the basic sense without issue. But as engineers, when something goes wrong with our tools we often don't immediately bring it into a mechanic. We need our tools to do very specific things, and we must understand what they did each time we perform an operation. We establish workflows that build on top of the tools and depend on the tool matching our precise expectations of its behavior. In essence, we are the mechanic for our own car. And of course, our needs are much more diverse than "make car go forward". So inevitably, we run into trouble more often. What user-facing function of a car is as precise, powerful or intricate as a textual merge or reconciling two diverged work histories? There are many ways those operations can be done, and questions the user must answer about their desired result.

xboxnolifes 3y ago
Based on your first paragraph, it's not all engineers who need an indepth understanding of git. Only git engineers.

codeflo 3y ago

> Do we think of pressing the gas pedal in a car as "accelerate", or as "regulate the intake manifold"? I'm just curious -- which of the two do you think is the correct mental model to safely drive a car? If you think its the former, my guess is you've never driven where there are mountains and/or never driven manual.

p-e-w 3y ago
The correct way to safely drive a car is intuition – not a "mental model" of anything. That's why experienced drivers drive so much more safely than novice ones. It's certainly not because in the meantime, they somehow learned how the throttle works internally. The same basic lesson applies to software. The best design is the one that lends itself most to human intuition. Because when saving a photo from an image editor, users sure as hell aren't thinking "now an inode is created with this and that metadata".
- codeflo 3y ago
  Intuition implies a mental model, just not a conscious one.
kelnos 3y ago
I've driven in mountains (I'm actually in the mountains, with snow on the ground, even, right now) and for 15 years drove manual (I sometimes miss it, but mostly do not, in the same way that I run Debian now and can't be bothered to run a distro like Gentoo anymore), but I literally never thought of pressing the gas pedal as "regulate the intake manifold". I honestly don't even know what an intake manifold is, though I'm sure if I cared enough, Wikipedia would tell me. Certainly my understanding of it is a bit more nuanced than simply "accelerate", but ultimately.... "press pedal harder, car moves faster" is... fine? Sure, you have to consider road conditions and (if driving manual) your current gear, speed, RPMs, etc., but... I dunno, I still think "press pedal harder, car moves faster" is a useful mental model to have, to some non-zero level of approximation. Put another way: if I were to think of all the details of what the accelerator of a car actually does under the hood every time I pressed it, and consider the implications of it and allow that to inform how I press the accelerator, I would have precious little time to actually drive the car... like, the things that actually matter, like steering and staying on the road and avoiding other cars and people and whatnot. When I press the accelerator, I think about the effect it's going to have on the car. And I have a good idea of what effect it's going to have based on my experience driving that car (or any car, really). Not based on any knowledge -- knowledge that I lack! -- of what pressing the accelerator actually does.

usr1106 3y ago

> is “how Git implements it” really the right way to explain it? >> Of course not, As long as the user is a software developer I would disagree. If the developer cannot understand the implementation concept style of explanation, I don't want to use or review their code either. I am saying implementation concepts as object storage, branches being pointers to objects etc. Of course implementation details and optimizations like packfiles don't matter. Every user-friendly explanation will have its limits once we get merges, rebases etc. For software developers it is important that their mental models don't hit such limits. If the user is not a software developer you have a point.

nonameiguess 3y ago

Both need to be known by someone but I still think this is a useful insight. The implementation details are key if you have to troubleshoot and want to know your tools at a deep level. It's also useful for anyone trying to implement their own version of a product with the same objective from scratch. You want to know the history of how something has been implemented by other attempts. That is a key priniciple of engineering in general. But ultimately, the implementation should involve choices and the possibility of change. git commit is saying the current state of the staged tree should be recoverable by any future user of this same repo. There are many possible ways to achieve this goal and how git happens to currently do it is worth knowing for some people. It's certainly been fascinating to read the months of output Julia Evans has put into this git plumbing exploration series. But I don't think it's critical for every single user of git to understand at this level of detail exactly how git works, and in principle, the developers of git should be able to change this without changing the semantics of what it means to commit in any user-facing way.