Maybe I really am just that good, but only a few of these "tips" strike me as targetted at intermediate users. Most of them seem to me like beginner information...
It's a mixture of basic and interesting tips, I'd much rather the interesting tips be separated out; feels like the author was padding the article out for the sake of a title.
Tip 12 looks suspicious, at least for the use case given. I'm not wild about storing passwords on a production machine, but if you're going to do it, don't kid yourself that gaining much by hiding it inside git's db.
Still, tip 12 was new to me, so I'd be interested in seeing a better use case.
The other thing to keep in mind is that `git gc` may prune loose objects that are created without any references.
"git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound)." -- http://www.kernel.org/pub/software/scm/git/docs/git-gc.html
I'm tempted to stuff tarballs in there for my pre-built release binaries, especially since I could give it a gpg signature in the tag. I wouldn't do this for large projects, but the case I have in mind is a tiny utility, ~25KB.
Does anyone know how github will handle tags pointing to a blob instead of a tree?
EDIT: On second thought, it probably makes more sense to have a "prebuilt" branch that has the actual tree of my release package. That would also let git share objects that are common to the source branch: README, manpages, etc.
The core of git is really simple. If you understand objects, hashes, blobs, trees, commits, then you pretty much know the basic vocabulary and you'll be able to learn more as you go.
