Week 3

Day 1 - "How do I see what's going on?"

Logging in Git

Perhaps the best feature of a version control system is the level of accountability that it offers if set up correctly. What do we mean by this? People often mistake the word accountability for the word blame. This is not true at all. Accountability is key in understanding the events that led up to a particular bug being introduced, or a situation occurring. How this is dealt with, is up to the management teams, but accountability should not be something that is revered, it should be something that is looked upon as a tool to help define the cause of a problem.

By its very nature, a version control system is also a logging system. Every time we committed something into the repository in the last chapter, we supplied a log message. In fact, if we don't supply a commit message, let us see what happens.

john@satsuki:~/coderepo$ git status

# On branch master

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#

#	my_third_committed_file

nothing added to commit but untracked files present (use "git add" to track)

john@satsuki:~/coderepo$ git add my_third_committed_file

john@satsuki:~/coderepo$ git commit -a -m "

Aborting commit due to empty commit message.

john@satsuki:~/coderepo$ git reset my_third_committed_file

john@satsuki:~/coderepo$

Git will actually not allow you to commit with a blank message. This is actually fantastic news, as people are far less likely to write a useless message than they are a blank one. It is very important that when using a version control system you write in a useful commit message. If you fixed a bug, say so. If you added a new function, why not put that in too. When someone wants to find out what a certain commit was for, or even when you come back to the project six months later and realise you've forgotten everything, log messages are crucial in piecing back together a history of development.

In the trenches...
"So John, I've been committing and all that," started Rob, "but how do I see the history of what I have done."

"It's really pretty simple," replied John, "But it really depends on what you want to know." Rob placed his thumb and forefinger onto his chin. "Well, for now, I just want to see a list of all of my commits."

"That one's the simplest of all."

At its simplest, git log will give an output of all of the commits that have been applied to the current branch. Depending on what type of machine you are using it on, the output from git log will be navigable, usually using the up and down arrows, with 'q' used to quit. Let's have a quick look at the output of our test repository and see what the log messages look like.

john@satsuki:~/coderepo$ git log

commit 9938a0c30940dccaeddce4bb2eb151fba3a21ae5

Author: John Haskins <john.haskins@tamagoyakiinc.koala>

Date:   Thu Mar 31 20:34:23 2011 +0100

    Finished adding initial files

commit 163f06147a449e724d0cfd484c3334709e8e1fce

Author: John Haskins <john.haskins@tamagoyakiinc.koala>

Date:   Thu Mar 31 20:32:59 2011 +0100

    Made a few changes to first and second files

commit cfe23cbe0150fda69a004e301828097935ec4397

Author: John Haskins <john.haskins@tamagoyakiinc.koala>

Date:   Thu Mar 31 20:27:44 2011 +0100

    My First Ever Commit

john@satsuki:~/coderepo$

The git log command shows us a chronological list of all of the commits to the repository and also gives us several more important pieces of information. In total there are four pieces of information displayed by default.

commit - This is the SHA-1 hash of the commit object that is stored inside the repository. You can find more information about this in the What's inside the Git repository? section Week 2. This is how we refer to the commit. If someone asked you in what commit you Made a few changes to first and second files, you could reply that you did that in commit 163f0. As explained earlier, it is good to remember that you don't need to remember or type out the whole 163f06147a449e724d0cfd484c3334709e8e1fce, only the first part is required. Generally, the first five characters will do.
Author - This is the name and email address of the author of the commit. When we begin to look at merging, you will see that the author of a commit, is not necessarily the committer of the commit. If you want to find out more about how to set these options, see the breakout box in this Week, called Changing your identity.
Date - The date is simply the date at which the commit was created. Again, note that when we start looking at merging, the date will be the date the commit was created, not the date it was merged into the repository.
Commit Message - This is the log message that was added along with the commit when it was created. Hopefully you can now see how important it is to create useful and meaningful messages in here.

Note - Note on Commit IDs

Please note, that if you are following the commits and changes on your local computer, you may not and probably will not have the same commit IDs as are presented in this book. You are advised to use them here to follow what is happening, but to substitute them with your own values, when you start working with the rest of this chapter.

Note - Changing your identity

Particularly when working with other people, or when publishing your repository to a public location, it's a good idea to make sure people know who you are and how to get in contact with you. Every time you make a commit to a repository, Git gives the opportunity to take note of who posted the commit. When you first install Git, it probably won't have the correct information in there for you, so it's important that you take the time to set this up.

To set up your name and email address, we need to modify use git config again.

$ git config --global user.name "John Haskins"

$ git config --global user.email

"john.haskins@tamagoyakiinc.koala"

That's it. Now by default, Git will use this setting whenever you commit to a repository, unless you override it by locally modifying the repository's .gitconfig.