Of course it is fun to know this but it won't help you understand git really, and please don't tell people who are just learning git. Just say git makes a copy of the whole project every time you commit.
A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit.
With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
git add --patchI don't need line-by-line usually (but it can technically do it if needed), but undoing accidental adds is indeed a bit of a pain.
Ultimately, I don't care what tools people use if they produce quality work and can integrate with the team without creating additional friction. There's nothing that says that a good GUI can't exist, or even be more productive than the CLI in some cases. I have had enough experience of GUIs causing problems, however, to make me nervous when I hear one is being used by a team member. It's often followed by something like: "I ran into a problem with Git, so I just deleted the repository and cloned it again."
Perhaps it's time for me to start looking at the available GUIs again, so that I can make a recommendation for a solid one when someone doesn't want to use the command line. In the end, though, one still needs to understand Git's behavior, to some degree, to be productive and avoid creating situations which take the team's focus away from our goals. I don't know that any GUI is going to help junior developers with that.
I want to understand git. But by that I mean using it. I don't need to know about the internals for that; I need to know common approaches to typical merge problems (where all of a sudden git loses a lot of its elegance).
"Oh yeah, space is cheap, so I just let my automated system make 10,000 commits per second. It'll be fine."
That was Google Wave, it stored everything as an "operational transform". The presentation they used when showing it off to the world was brain damaged, they insisted as showing it off as a ton of separate blocks, instead of one continuous document, which gave people the wrong impression of it, and tanked it.
In a similar way, the impression that Git stores deltas, got stuck in my head somehow at the beginning and made it an opaque mystery for me.
It was only years later, when I somehow I managed to learn the truth, that Git stores full snapshots, and except for compression in extreme cases to save storage, it doesn't do anything with deltas (except fake them to show diffs)