A lot of people are confused by git. Most of these people, I reckon, learned it from the outside in - from the command-line interface down. If you started with git by asking "how do I sync up my changes with my peers", then you might get the answer, but you will be missing the foundation on which that answer is built. This is the main source of confusion with git.

The better way is to learn git from the inside out. You should first learn about what objects are and how they're stored and identified, and how they relate to each other. You should learn what blobs, trees, and commits actually are, and how they relate to each other, and how commits form a linked list from which a graph of all objects can be derived.

Then you should learn how the ref database gives friendly names like "master" and "feature/foobar" to objects, and how the reflog tracks changes to references over time.

THEN, and only then, should you learn how to use the CLI. Then you can learn about using the staging area to add objects to the database and create commits, and how doing this updates the reflog.

Git makes total sense when you approach it from this angle. Supposedly hard tools like git rebase are totally understandable when you view them with the appropriate foundational knowledge.

Git is a tool which you will reach for hundreds of times a day, every day, for your entire career. Maybe it's worth learning about properly.

@sir I don't think so. That's like you have to disassemble and reassemble your car before you're allowed to drive. Good software should be usable and understandable without having to know about every tiny internal detail. In my opinion, #Git is exposing too much of its internal structure.

@ls @sir Myself, I don't worry about /how things are stored/ (e.g. blobs, trees, huh?); I just know it's a directed acyclic graph of commits, branches are movable pointers, and that's plenty.


@IceWolf @ls it's really easy, though. Blobs are files, tress are lists of files and other tress, and commits relate previous versions of trees to each other with a message explaining what changed and who did it.

@moonbolt @sir @ls Yeah, exactly! Most people don't need to know anything about blobs and trees. It'll just be confusing and a turn-off. If you know what a /commit/ is and how they relate (i.e. commits are changesets, and it's a tree of commits [technically DAG, but saying tree to start with is less intimidating]) then you should be good, I'd think.

@IceWolf @moonbolt @ls strong strong strong disagree, this is my entire thesis man

@sir @moonbolt @ls But like, why do you need to know about the internal storage format? It's not like you need to be digging around in there. It'd be like asking people to understand how ext4 works before they can use Linux. It's just /not a concern/ at the user level.


@IceWolf @sir @ls Not that elegance isn't nice. But we badly need sound abstractions: otherwise we'll end up with ecosystems that have impossibly high barriers to entry, because before you can do anything, you need to know the theory and internals, which requires a good understanding of the theory and internals of everything it's based on, which requires a good understanding of…

@moonbolt @sir @ls *nods*

In my opinion Git already /has/ those abstractions in place. I don't really know what a "blob" or a "tree" is, and I don't much care. I can still do all sorts of fancy things. I don't /need/ to know.

@moonbolt @IceWolf @ls ah yes, the slippery slope argument. You start with blobs, trees, and commits, and then before you know it, 14 years has passed and... tags. Tags are the only other thing which has been added to this model in 14 years.

Sign in to participate in the conversation
Interlinked MST3K

this is mst3k