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.

It's also worth knowing that you can implement a useful subset of git with shell scripts, inside of an afternoon. This is how large swaths of git were implemented in the early days!

@sir I explained how git's filesystem works to my boss the other day

it's nearly a text-based format (there's one place where it uses a single NUL byte)

@sir I haven't had problems with git, but people get confused by inconsistent command lines. For example, checkout means switching branches or using a file. There are also ambiguities around checking out a branch by name, SHA1, or filename.
@sir oh, and how rebase's commands are inconsistent. But it's not too hard...

@farhan checkout makes sense when you understand it incontext. Switching branches and "using" a file (what does that mean? Do you mean resetting a file?) are the same fundamental process in git. Again, you're looking from the outside in when you should be looking from the inside out.

@sir @farhan `checkout` does seem…inconsistent? weird, to me. `git checkout $branch` changes HEAD, but `git checkout $commit_ish $path` doesn't. I think `switch` for the former and `restore` for the latter make more sense.

@moonbolt @farhan changes HEAD, and then checks out everything to make the world consistent.

@sir Could you recommend some ressources where beginners could start reading?

@waweic @sir The git book is free and online. I bought a copy a while ago that I have been needing to read.

@waweic @sir I second this, does anyone have a good primer they wouldn't mind sharing?

@sir and yet, I still butcher my repos with rebase. Every damn time.

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


@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 @moonbolt @ls "It's not like you need to be digging around in there."


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

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

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

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


Probably doesn't help that there's no lesson on it in Computer Science schools and college, in France at least, you're supposed to learn it by yourself :/

Gave a course on git to my colleagues the other day and I did precisely that. The plumbing *then* the porcelain

Sign in to participate in the conversation

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