Hacker News new | past | comments | ask | show | jobs | submit login

I'm not sure that people are (generally) arguing that learning how git works internally is required to use the tool. The thing I see repeated a lot is that learning how it works isn't as scary as it seems and will give you a really good understanding of what it's doing and why. Given that such advice is aimed at software developers, it doesn't seem that outlandish, either.

Also, you absolutely should understand how a debugger works to get the most out of Visual Studio. If you understand how the clutch and torque setting on an impact driver works you will have a less bad time using one and the tool will last longer. <add your own car analogy here>




The thing with git is that learning the general idea of the internals is not enough. You can learn enough about git to visualize a DAG of nodes identified by hashes, but what does that get you? You still have a thousand higher-level commands that build on top of it, and for each of those you have to learn how what it does translates into nodes and hashes.

The higher level commands are not individually leaky abstractions. But you can't connect them at a higher level of abstraction. In order to understand how "git foo" relates to "git bar", you go through the lower layer.

So git has you learn:

  1. The fundamentals.
  2. A thousand higher-level commands.
  3. How each of the higher level commands translate into the fundamentals.
Version control is supposed to be a tool to help me, to take away chores so that I can focus on other, more interesting, things. This is not something I want to invest a lot of time on. Even as software developer, most of time when I use software I'm just a user, and I want the tool to do its job and get out of the way.

Car analogy: I drive cars and leave the rest to the mechanics.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: