Getting Git, part 1 #
hacking, January 24th 2008
Many people — me included — find Git really nice, but equally many seem somewhat confused by it. I think this is due to Git being conceptually different compared to other VCS we're used to: unless you have an at least mostly correct theory of Git your expectations based on experiences with other systems will lead you astray.
This is the first part in a series of posts that tries to address this issue, by providing the aforementioned theory. In this part I talk about general concepts: the terms I use are not Git terms; I'm trying to start you thinking in a Git-compatible way as opposed to whatever CVS and others have taught you over the years. Details and real terms will start in the next episode.
Ready? Buckle up!
Git stores content, not metadata. Some of the data stored by Git may very well describe some other data also stored by Git, but it is all content to Git.
Git stores content, not changes. It can reason about changes in content, but only content is stored.
Content is identity. If two "things" have identical content, they are the same thing for Git.
Content is immutable. If you think you are mutating something stored by Git, think again: what you're doing is making an altered copy and possibly throwing away the original. Since content is identity, you cannot mutate an object and have it retain its identity.
That's it.
I hope this was simple enough, but if you've had trouble understanding Git before, please review the points above a time or two to make sure you understand what I'm saying. You don't yet need to understand how the points above relate to Git — just try to grok das Ding an sich. When you think you have it, ask yourself:
Conan! What is best in life? What does Git store? How would
you describe this stuff that Git stores?
Next time we'll pop open the hood and see what's inside.