Git is one of the best examples of "great tool with terrible API".
Funniest thing is that people always argue "learn git internals and it'll click"
Yea, git is the only tool that people argue with straight face that you should know internals of software and act as if it wasnt sign of terrible API design.
Imagine if people acted as if you needed to know Visual Studio's or Firefox's internals in order to use those tools even in "far from very advanced scenarios", rofl.
Yes I don't know how anyone can come to the conclusion that the CLI isn't by far the biggest problem. It is terrible.
The other big issue is that people tell you not to use a GUI, and there are a lot of GUIs that are not very good. Using a good GUI (I recommend GitExtensions, GitX on Mac or Git Graph in VSCode) makes Git waaaay easier to understand because the model is literally drawn for you.
Find me a Git tutorial with no diagrams and I will change my mind.
Also the author's "these are core facts about Git" list is not very accurate so I'm not sure how much they really understand it. A commit is not a snapshot and a patch. It is literally only a snapshot.
Edit: I actually searched Git tutorials and there are a surprising number of terrible Git tutorials with no diagrams! Though I guess I shouldn't be surprised about the official Git tutorial and W3Schools.
> A commit is not a snapshot and a patch. It is literally only a snapshot.
When you do cherry-pick, you supply a commit id, but actually a patch (diff between the commit and its parent) is applied. So yes, commit (/id) can mean a patch in some cases.
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.
You should understand the internals of tools that you use. Abstractions and simplifications do only one thing: delete features in the hope of being easy to understand.
As a software engineer you have the unique privilege where the people that make your tools have literally the exact same job as you, so you can pretty easily understand their work.
As for understanding Visual Studio's or Firefox's internals, that's basically what you do to write Visual Studio plugins or apps that run in Firefox.
>You should understand the internals of tools that you use. Abstractions and simplifications do only one thing: delete features in the hope of being easy to understand.
Just because you should understand internals, it still doesn't mean that git's cli isn't terrible.
Also I don't have time nor desire to understand internals of all software that I use
do I have to learn internals of github, jira, email client, teams/discord/slack/irc, power point, etc, etc?
They have similar or higher value to git in work setting (I mean I could switch to other letters management system)
VS and Firefox don't demand you understand writing plugins to use them.
They wrap their internals with an interface that has well documented entry points, but you don't need to delve into them to get a lot of value out of them.
> As a software engineer you have the unique privilege where the people that make your tools have literally the exact same job as you, so you can pretty easily understand their work.
That's not how that works. Writing frontend apps doesn't teach you MUMPS.
_
At the end of the day Git gets "easy" but honestly most people who say Git is easy are like people saying JS is easy: the people who know either well enough will claim anyone who thinks either is easy simply doesn't know them well enough
Linus himself: Generally, the best way to learn git is probably to first only do very basic things and not even look at some of the things you can do until you are familiar and confident about the basics.
When I work with graduates, I often encourage them to try and understand "1 level down" - that is to say, understand the general design philosophy and how to navigate the tools and libraries you are using. That gives you a better understanding for how to use them, whilst also allowing you to side step the documentation when you need to. On the other hand, if you try to understand what the atoms are doing on the silicon when you run an SQL command, you might be a tad overwhelmed...
Some of it might be inherent though. The data structure consists of immutable commits which are addressed by the SHA1 which depends not only on the snapshot but also the metadata as well as the SHA1 of the parents. You run into this immediately when someone thinks that they can maybe just tweak the commit message a little and end up with the same commit. Or drop the second parent of a merge commit in order to “forget” that line of history (effectively making a “squash merge”).
Imagine if someone was working on a SQL database and they thought that an `update` would not change anything in-place but instead would create a new immutable row and that they could reset back to the previous row (before the update) right after that since the immutable row (they thought) would still exist until some arbitrary garbage collection time. You would end up having to explain the same thing but kind of reversed.
Nah, really, it is terrible.
Git is one of the best examples of "great tool with terrible API".
Funniest thing is that people always argue "learn git internals and it'll click"
Yea, git is the only tool that people argue with straight face that you should know internals of software and act as if it wasnt sign of terrible API design.
Imagine if people acted as if you needed to know Visual Studio's or Firefox's internals in order to use those tools even in "far from very advanced scenarios", rofl.