Git Magic - Preface | Hacker News Reader

Git Magic - Preface

www-cs-students.stanford.edu

70 pointsgraywh10 comments

Yet another Git tutorial. I've found that it's impossible to master Git by treating it like a black box- one _must_ understand how it works to truly understand it.

This is exactly why I wrote my tutorial:

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

It's pretty sad that this one not only assumes that knowledge of the internals is unnecessary, it in fact praises such ignorance ("newbies can ignore its inner workings and view Git as a gizmo that can amaze friends and infuriate enemies with its wondrous abilities"). This is particularly true considering that the relevant parts of the Git internals are actually quite simple.

Your life is too short to learn and understand the internals of everything. The less I have to know about the internals, the more leverage a library or framework provides me.

Secondly, what is 'quite simple' to you may be incomprehensible to someone else. However, I still have to collaborate with these people on a project. If git is ruled out, because only the top 1% of people in software engineering can gain a sufficient understanding of the internals to use it, then it is utterly worthless to me.

The one which helped me the most was a moderately technical tutorial entitled GIT for computer scientists.

http://eagain.net/articles/git-for-computer-scientists/

Yeah, I liked this one too! See also gitcore-tutorial (7)

Master, sure; that takes a (long) while. But one: you've got to start somewhere, and two: Chapter 8 (http://www-cs-students.stanford.edu/~blynn/gitmagic/book.htm...) covers this.

I understand Git's internals well enough, but I don't, nor have I tried to understand the actual packing heuristics, nor do I believe that I need to, to be good at git. (Recent HN posting on the packing heuristics: http://news.ycombinator.com/item?id=1058204)

I don't understand packing heuristics either, and no, you don't need to understand it to be good at Git. What you do need to understand: what commit objects really are, and how they're connected to each other. This should cover branches, tags, rewriting history. There's no point describing porcelain commands in great detail: that's what manpages are for.

About starting somewhere, I agree. There are plenty of "cookbook tutorials" to take you through some everyday scenarios. In my opinion, it's much easier to screw up with Git than with SVN: so when this does happen, it's time to move onto understanding the internals.

sorry, but I disagree that it's easier to mess up in git. case in point, the rm command. in git the rm command will not destroy the existence of any actual data, in subversion it will. so an "accidental" rm in git looses you nothing but time in reverting correctly, in subversion you loose data, which is irrecoverable. similar things can be said for almost any git command. and those that could loose data require a force flag, almost every time.

I'm showing this to my version control-challenged co-workers first thing in the morning!

this has been my most useful git tutorial, or more importantly, reference. it's great to come back to for how to deal with a situation that doesn't come up often enough, but when it does you need a concise answer on how to handle it.

Reply on news.ycombinator.com