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.

Follow

@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, is exposing too much of its internal structure.

@ls I think the line of thinking which treats git's internal structure as... internal, i.e. something you shouldn't be aware of, is mistaken. Being aware of those internals gives you an understanding which unlocks a lot of powerful tools, workflows, and options.

@sir Yes, it surely does. It helps to know how thinks work, that's true for a car, too. But requires you to know about the internals but a car doesn't. I think Git is (one of) the most powerful repo systems we have, but it's still poorly designed. I don't like that rebase-stuff. In my opinion, the history should be strictly readonly.

@ls I mean, but we're not talking about the suburban mom driving the mini-van to drop the kids off at soccer practice. We're talking about professionals. Should a racecar driver not understand how cars work?

@sir A race car driver is not a gear box or drive train engineer, that's a different job profile. I think, professionals appreciate tools which help them do their actual job and are not a project by itself.

@ls @sir @ Lars thank you for articulating the reason the OP position was rubbing me wrong, I saw this thread in the early morning but didn't have time to put together a thoughtful response

@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.

#Git

@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.

@IceWolf @moonbolt @ls "It's not like you need to be digging around in there."

GAH

@sir @moonbolt @ls I mean, when /would/ you need to go digging in the .git folder? With things like rebase and filter-branch, I've never needed to myself. Data recovery /maaybe/, but I wouldn't expect regular users to need to know how to handle that.

And for redacting private things that shouldn't have been committed, also maybe – but we have tools for that.

@sir @IceWolf @ls I confess I just think of "files and trees," not "blobs and trees." Knowing what branching is absolutely helps me, but knowing precise git-speak so far really hasn't. :)

@arilin @sir @ls Honestly, I think this is probably where I'm at too. I probably already know what a blob and a tree are, I just never put a label on the concept.

Sign in to participate in the conversation
Mastodon @ social.lsnet.eu

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!