I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it.

However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.

You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it.

FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc

500 pages (excuse me, 501) to document a source control tool.

Something went very wrong here early on. But, lacking a time machine and a handgun, it's clearly unfixable.

Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.

This seems wildly optimistic.

The first 6-7 chapters should teach you more than most Git users know (myself included, suppose I might be due a re-read!).

1, Source control can get very gnarly when you have multiple editors on a codebase, and 2, good and comprehensive documentation for software is often many times longer than the software it documents. Man pages are a lot longer than -h

I use this whenever I need to look up anything outside of our workflow, but don't believe internalizing the myriad of git details has a very high pay-off. There's probably higher value knowledge in your role that you should prioritize.

The payoff comes when you develop a mental model of Git's data structure design, which is stuff like "a branch is a named pointer to a commit" and "the central data structure is a content-addressable store" — and most germane to this thread, "the source control tree is a diagram, and the operations one does to it are diagrammatic". (Thanks mjburgess!)

Learning Git's infinity CLI options won't teach you that.

Does not still fix the root cause that Git is super-bad as an industrial tool - actions that should be trivial push-button activities become incomprehensible command line character soup.

The fact there is a book on the subject speaks volumes about how bad it is.

Like what?

VCS should be trivial push-button activity (and _is_ except with Git). There is no added value making a thing far less usable than could be. This is not git’s fault - it is what it is. But it is incomprehensible industry selected it as it’s de facto vcs.

Give an example of an "action that should be a trivial push-button activity" that requires "incomprehensible command line character soup".

All of them. A command line should not be the default option.

Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.

If the existence of a book speaks volumes about how bad something is or is not, I have some bad news for you about what's inside libraries. What beloved subject doesn't have a plethora of books written about it?

Exactly. VCS is part of an industrial process. It's not supposed to be implemented with a thin wrapper to a database whose node structure you need to rummage through.

The software analogue would be that in order to use the platform default List and Dictionary data structures you would need to manually manage the links between the data nodes.

Or to use text editor you would occasionally tweak the rope datastructure or equivalent. Etc.