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.

Indeed, Scott Chacon's technical explanations of Git provided my biggest gains in understanding.

http://vimeo.com/14629850

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

[1] http://www-cs-students.stanford.edu/~blynn/c/

[2] http://vimium.github.com/

Thanks, for both links

Yes, I think it's extremely irritating.

Previous discussions:

http://news.ycombinator.com/item?id=161867

http://news.ycombinator.com/item?id=267462

http://news.ycombinator.com/item?id=1064027

I'm sitting next to Ben right now, and he's blushing at all the attention. He says he keeps meaning to do a v2.

Anyway, if you really like this, you should consider getting a physical copy: http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/

Hey Ben,

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.

So, you know, pretty please? :)

Any chance of a Kindle/ebook version? It's already free online, but it might make for a bit more pleasant reading on a tablet/mobile device.

The source[1] is in asciidoc format, use a2x [2] to convert it to epub.

[1] git clone git://repo.or.cz/gitmagic.git [2] http://www.methods.co.nz/asciidoc/a2x.1.html

What do they mean by the below in the Git shortcomings section:

Git on MSys is an alternative requiring minimal runtime support, though a few of the commands need some work.

Need some work on what? I hate it when some statements are made without giving any explanation

From ReleaseNotes.rtf

Known issues -Some commands are not yet supported on Windows, namely: git archimport, git cvsexportcommit, git cvsimport, git cvsserver, git instaweb, git shell. -git and bash have serious problems with non-ASCII file names (Issue 80, 159)

There are other known issues, but I think those are the most important.

And this one:

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.

There are simpler tutorials: http://www.jperla.com/blog/post/teach-yourself-git-in-2-minu...

This is hard for me to understand with the abbreviated commands.

The Simplified Chinese version looks like a machine translation.

I didn't think I would like this. I'm a nuts and bolts kind of person and I like to try to understand from the ground up if I can.

However, this is a pretty good narrative, and is filling in some blanks for me. For instance, the git whatchanged command was new to me.