Join Kevin Skoglund for an in-depth discussion in this video Getting more from the commit log, part of Git Essential Training (2012).
In this movie, we're going to talk about how to get more from your commit log. We've already seen the basics, and we want to see what's in our log for our repository, we can say git log. That returns a paginated list of everything that's in our git log, and if we hit space it will just keep going until it gets to the end, and Q will quit of it. So that's the basics of git log, but there is a lot more we can do with it. In fact, I really encourage you to go look at the Git help pages for log, because there are so many options there. You can really fine-tune exactly what you are looking for and tease out the information about the commits using all of these configuration options, but I'm going to highlight some of the most important ones.
The first I think is just git log --oneline. I think it's probably the single most useful option, because it just gives us a oneline list of what's in our log file, instead of having that long scrolling list, it just compresses it for us. It still gives us part of the SHA here that we can use to reference each one those commits if we want to work with it. We can also use a number of commits to limit the number of commits that it goes backwards, so, for example, -3 will show us just three commits, -5 will show us five commits. We can also filter the log by time period.
So for example, git log, and then we can use the since option, since equals and then in quotes, and we can put a lot of things in here for the time. For example, 2012-06-20, and it understands that as being 2012 June 20th. Hit Return, and that's what it gives us, just the entries that are since then. We can always use after instead of since, those are synonymous. We can do the same thing, but use until so that's all the commits that are until that date, and we can use before as well. So before and until both work the same way, and we can of course combine both of those. We can pass in the time period in other formats as well.
So for example, 2 weeks ago, just as a string, and it's able to figure this out. Say 3 days ago, so there's everything from 2 weeks ago until 3 days ago, again paginated, hit Return at the end, and you can even do it just by saying 3.days and 2.weeks, and it's able to understand that as well. So any of those formats will all do the same thing. You have a lot of flexibility in the way that you specify the time period that you want to use.
We can also search by author, so author this is the person making the commits, I can say I'm looking for everyone with Kevin and the author, so if there were multiple Kevins, it would show all of them. Instead if I wanted just Kevin Skoglund then of course, I would write in my name there, and now it shows me just author Kevin Skoglund. We're the only one making commits at this point, but if we are collaborating with other people, it's nice to be able to filter out and see, what are the commits that John made? I want to see John's commits only and see what he was up to last week. We can also GREP the commit messages. GREP is a global regular expression search, so we can do git log --grep equals and then whatever regular expression we want to search for we can put here in quotes. So I'm going to search for temp, and that'll return the two things that had a message that were about the temp file, and see both of those.
This is really nice if you want to see everything that was committed about a certain topic. You can see now why having good commit messages is really, really helpful, because it allows us to be to search for things in the commit message that apply to the particular section of our code that we might be working on. We can also specify a range of time periods, let's do just a regular git log, oneline, so here we are, and let's say we want to see all the commits from this commit, do git log, and then put that SHA in dot, dot. That's how we indicate a range, all the way up to let's say this one. So this will show me just those commits, and I'll go ahead and do it as one line again, so it's really clear what it's doing.
So now it's showing me just those from that commit up to that commit, so that's how we use a range. We will be using those again a little later on. We can also ask it for information about what happens to a particular file. For example, I could say, tell me everything that has happened since the initial commit, git log from initial commit going forward to, and I could put in a commit or I can just leave it blank, nothing at the end of the range will say all the way up to the end, what has happened to the index.html file. Give me the logs that affect that file, let's try that.
There is one commit that's relevant to it, it's this commit right here, and this is what changed to that file. So if you're working on a particular file, and you want to go back in history, and see what's happened to that file previously, the log will let you do that. We can find out more details about the commits by using git log -p, this is the patch option, and it shows us a diff of what actually changed in each one of these. So here's the additions and here's the subtractions. So we can really see what's different about each one. That's really nice, especially when we're working with this, find out what happened to each one of these files, because we can jump back here and right after log we'll put it in the -p option, and now not only does it tell me what commits apply to this, it actually shows me the changes as well. So I can do both, all right here, every single change listed out that happened to the index.html file.
We can do something similar also with git log --stat and --summary, and you can use those separately or together. What they'll do is they'll tell you statistics about what changed in each one, so you see here this, the git ignore file added whole bunch of things. Here in resources, something was added and something was taken away, and it goes ahead and gives you a little summary here as well, that's what that summary is. That's nice if you're not as concerned with the actual details of what happened, you are just wanting to get an idea of the quantity of things that changed and where.
So as far the log format goes, we saw the most useful one, already which was the oneline, and git log --oneline is one way to do it, git log format equals oneline is another way to do it. Now this returns a slightly different thing, because it returns the full SHA instead of just a partial SHA, so you can compare the two, oneline, oops, I misspelled it. There it is, so you can see the difference between the two of those. We can also specify other formats though which is why it's nice to know about the format version, because in addition to saying oneline, we can also use short or we can use medium which is the default one that we already seeing, we can see full, that gives us a little more information, like the commit author, and there's fuller which gives us even more information.
There is email, which generates it in a format useful for mailing an email, and then there's raw. It's really showing us the raw information that's stored in Git. The last one I'm going to leave you with is one that I think is pretty cool, git log --graph. So this shows us a graph of each one of our commits. Now right now our graph is pretty straightforward and linear, but if we start having branches, and we start branching thing off and then merging things back in, then this really shows us those branches are merged, so we'll come back and try that a little later.
A nice combination of them is git log --oneline --graph --all --decorate, so let's put all those together, and you'll see that it gives us a nice compact list. It'll show all the branches that take place and even tells us right now that this is where the HEAD is pointing, and this is the tip of the master branch. So this is a nice combination of options that's worth remembering. Please experiment, find more, dig through the log files and find formats that are useful for you in the way that you like to work.
- Exploring the history of version control
- Installing Git on Mac, Windows, and Linux
- Initializing a repository
- Writing useful commit messages
- Understanding the Git three-tree architecture
- Tracking when files are added, edited, deleted, or moved
- Viewing change sets and comparing versions
- Undoing changes and rolling back to previous versions
- Ignoring changes to select files
- Creating and working with code branches
- Merging branches and resolving merge conflicts
- Stashing changes for later
- Working with hosted repositories and remote branches
- Developing an effective collaboration workflow
Skill Level Beginner
Q: In the Chapter 10 movie "Configuring the command prompt to show the branch," when I type the function "__git_ps1," I do not get the expected result.
A: The function "__git_ps1" was recently moved to a new file, .git-prompt.sh, as described here: https://github.com/git/git/commit/af31a456b4cd38f2630ed8e556e23954f806a3cc.
We will update the video. In the meantime, you may do the same steps you do for .git-completion.bash, but a second time using ".git-prompt.sh" as shown here: https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh.
Q: When I use the code the instructor advises in the above video ("git config --global user.name "Nelda Street"), I still get an "Illegal Instruction" error. I have OS 10.6.8. Am I doing something wrong?
A: The current installer version of git isn't compatible with older Mac OS versions.
1. To add "-mmacosx-version-min=10.6" as described here:https://stackoverflow.com/questions/14268887/what-is-the-illegal-instruction-4-error-and-why-does-mmacosx-version-min-10https://stackoverflow.com/questions/10177038/illegal-instruction-4-shows-up-in-os-x-lion
2. Or to use the version of git that comes with Xcode, or to use homebrew to install git instead.http://superuser.com/questions/697144/installed-git-not-sure-how-to-get-it-working