[wpietri]

C is a great example here. If you write a lot of C, you really have to understand pointers very well. And quite a lot else. That makes it a bad tool for many purposes, so most developers do not use it, and fewer use it every year. It's just a bad tool for modern purposes.

The same applies to the git CLI. And really, to git. The right tool for a small group C-using kernel developers 15 years ago may not be the right tool for different people doing different things today. Let's hope it goes the way of C.

[Espressosaurus]

Except you don't need to know the git CLI except when you've screwed something up. Even the reflog is available via TortoiseHg. Bisect okay maybe you have to drop to the command line, but otherwise there's no reason to futz about it when you can checkout, merge, rebase, cherry-pick, create new tags, etc. using the GUI.

My experience is that knowing the DAG in GIT is equivalent to needing to know pointers to write effective C.

Knowing the internals is more like needing to know assembly in C. Yes, it can be really useful for debugging certain classes of problems, but not really necessary in day-to-day work.

I've used git professionally for 4 years now and haven't once run into a corrupted repo or a problem googling for help couldn't solve. Day to day driver is TortoiseGit, which is frankly just a shitty TortoiseSVN skin on top of git. But I like being able to visually see the graph since at the end of the day I'm doing graph operations when manipulating the repo.