All these git tutorials are nice, and they might be beneficial for some people.
Personally, I find all these supposedly-helpful analogies useless and confusing. If I start to learn git, I would rather someone just tell me three things:
1. Git saves 'entire' snapshots of a directory on each commit.
2. Each commit resides in a graph and has a pointer to its parent
3. The only commit with more than one parent is a merge commit - which carries data on how to merge two previous commits.
<pedantic>There are also root commits that have zero parents (a repo can have multiple roots). A merge commit differs _only_ in that it has more than one parent; it otherwise carries no additional data compared to any other commit.</pedantic>
The special treatment that you see when you "git show" a merge commit is computed by comparing the merge commit's tree to its parents' trees.
I'd also add a (4) to your list: a branch is a pointer (a "ref" in git jargon) to a commit that is updated to the most recent commit each time you create a new commit.
Oh, and maybe (5): HEAD is usually an indirect pointer to a commit via a ref, but can also point directly to a commit in which case it is a so-called detached HEAD.
You can even have repositories that only have root commits. I have a git hack that stores blog entries in a git repository. Each entry is a root commit with one branch that points to all of the root commits. A fun crazy hack.
This is where I like Darcs. Your hack is actually the default there, because it is "obvious" that a patch representing a new blog entry doesn't depend on anything.
There, reverting any such patch would simply delete your entry without any more question (unless of course you committed another patch on top of it to, say, correct spelling). I assume this is the kind of advantage you get from your hack?
Yup I saw it a each "blog entry" being its own repository with its own history of corrections, updates etc. There was multiple master branches that groups blog entries such as "public" or with other tags. The real fun came because you could publish your git repository and when someone fetched it if they say used http they would only get the public branch and all those commits, but if you fetched using the key "bob" you could get all of the refs that were both public and bob. Those on the public branch would never know that they are missing refs because they have separate roots. And just to make things more fun you could have encrypted messages to boot with private keys.
> 1. Git saves 'entire' snapshots of a directory on each commit.
Every time I've tried to explain this to someone who doesn't understand how gits content addressable data-store works, I've been met with disbelief or mockery. These days I just point people to the docs.
Yeah, I don't why people don't understand persistent key/value stores using a has as the key. Its no different than any other typical use of any other typical kv store (such as BDB and such).
Git is rather well engineered for what it set out to do.
So, off topic a little here, but does anybody else find the "title" attribute on the main content divs to be very irritating? Apparently I read with my mouse cursor sometimes (I didn't realize I did this), and that pesky "title" attribute constantly causes a tooltip to get in my way.
Yes that has bugged me quite a bit; I first noticed it when reading his essay on C [1]. But since then I've installed Vimium [2] and I never even touch the mouse anymore.
A request for v2 -- I'd like more on topic branches, and good git hygiene. I usually send people to your book, and in fact, I learned my first git from it.
In the end, though, it encourages using git as a sort of backup-and-restore system, which is not the best and highest use of git.
The best and highest use of git is going to involve rebasing, collecting up and properly naming your commits, and making CERTAIN that one commit does one atomic thing to your codebase.
This just wasn't that obvious to me from git magic, but I think in the end it's the best part of git as a whole. Once I get people to stop using git reset --hard, my next training task is usually what I just described.
Git may be disadvantaged more than other systems because single files are not tracked
Though I get what they are trying to tell here ( I know git to an extent), a newbie will definitely be lead down the wrong path with this line. I am doubting this entire thing has any magic at all.
Personally, I find all these supposedly-helpful analogies useless and confusing. If I start to learn git, I would rather someone just tell me three things:
1. Git saves 'entire' snapshots of a directory on each commit. 2. Each commit resides in a graph and has a pointer to its parent 3. The only commit with more than one parent is a merge commit - which carries data on how to merge two previous commits.