We analyzed a commit, and the information supplied by a simple git log; but we are not yet satisfied, so go deeper and see what's inside.
Using the git log command again, we can enable x-ray vision using the --format=raw option:
[14] ~/grocery (master) $ git log --format=raw commit a57d783905e6a35032d9b0583f052fb42d5a1308 tree a31c31cb8d7cc16eeae1d2c15e61ed7382cebf40 author Ferdinando Santacroce <[email protected]> 1502970693 +0200 committer Ferdinando Santacroce <[email protected]> 1502970693 +0200 Add a banana to the shopping list
This time the output format is different; we can see the author and committer, as we saw before, but in a more compact form; then there is the commit message, but something new appears: it's a tree. Please be patient, we will talk about trees in a couple of paragraphs.
What I want to show now is another command, this time a little bit more obscure; it's git cat-file -p.
Let's try this command. To make it work, we need to specify the object we want to investigate; we can use the hash of the object, our first commit in this case. You don't need to specify the entire hash, but the first five-six characters are enough for small repositories. Git is smart enough to understand what's the object even with less than the 40 characters; the minimum is four characters, and the number increases as the total amount of Git objects in the repository increases. Just to give you an idea, the Linux kernel is currently 15 million lines of code, with millions of tracked files and folders; in that Git repository[1], you need to specify 12 characters to get the right object.
When in need, I usually try typing only the first five characters; if they are not sufficient to make Git aware of the object I need, it will warn me to input a character or two more.
Back on topic; type the command, specifying the first characters of the commit's hash (a57d7 in my case):
[15] ~/grocery (master) $ git cat-file -p a57d7 tree a31c31cb8d7cc16eeae1d2c15e61ed7382cebf40 author Ferdinando Santacroce <[email protected]> 1502970693 +0200 committer Ferdinando Santacroce <[email protected]> 1502970693 +0200 Add a banana to the shopping list
Okay, as you can see, the output is the same of git log --format=raw.
This is not unusual in Git: there are different commands and options that end up doing the same thing; this is a common feature of Git, and it's due to its organic growth across the years. Git changed (and changes) continuously, so the developers have to guarantee some backward compatibility when introducing new commands; this is one of the side effects.
I introduced this command only to have the chance of introducing another peculiarity of Git, the separation between porcelain commands and plumbing commands.