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, 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

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!