Tips for Intermediate Git Users | Hacker News Reader

Tips for Intermediate Git Users

andyjeffries.co.uk

158 pointsrohitarondekar15 comments

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

Agreed, though it's still nice to find the odd command or two that slipped through the cracks. I didn't know about these:

$ git log --grep="Something in the message"

$ git log -S "TODO: Check for admin status"

The intermediate stuff starts after #10

"1 Way To Go Against HN Guidelines"

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.

Was the headline edited after this comment? It seems fine to me now?

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

Note that he does add a tag to the object he creates, presumably so it doesn't get collected.

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.

Bad name: 25 Tips for Intermediate Git Users

Good name: Tips for Intermediate Git Users

Better name: Tips for Beginners to Git

Great tips.

Git is arguably one of the best pieces of software created in the past decade.

Its learning curve is definitely steep, but it's exactly tips like these which give a perspective of Git's true power.

I didn't find the learning curve to be steep.

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.

This is a really good explanation for these basics: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

I think the learning curve tends to be steeper if you have to "unlearn" some of your preconceived notions from using a centralized VCS.

How about just trying to unlock all of the git achievements. Do that and you will discover a lot about git.

Reply on news.ycombinator.com