On Fri, Dec 10, 2010 at 3:46 AM, Konstantin Khomoutov
> On Nov 24, 2:20 pm, Roddie Grant <gitl...@myword.co.uk> wrote:
>>> To make things simpler to grok, you can think of all those three types
>>> of objects as being plain text files.
>>> Playing with `git ls-tree` and `git cat-file` can give a very clear
>>> idea about how objects reference one another.
>> Thanks Konstantin, that's very helpful. I'm still trying to conceptualise
>> how Git works, and your reply has filled in a few gaps.
> I recently came across this paper  which you may find useful as it
> tries to explain Git on the object level, showing the precise steps
> Git performs to create a new commit.
> I've spotted one minor deficiency in the article so far (there's no
> such thing as the "HEAD of the current branch" as Git maintains just
> one HEAD ref)
.git/HEAD contains an indirect reference to a git ref so, if I'm
working on the branch foo
so there's a heads ref for each branch known to my 'client' machine
These are the sha hashes of the last commit on each of the branches.
When you do a commit, git uses the ref pointed to by the refs file
pointed to by HEAD as the base for the commit, i.e. what to use to
diff against to determine what has changed. At the end of the commit
the ref is updated with the new SHA.
In the case of a detached head, for example if you checkout using a
SHA rather than a branch or tag then the contents of .git/HEAD will
simply be that SHA. In this case git doesn't know what branch you are
on, in fact that commit may appear on more than one branch or no
branch at all.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at