What does git log show me?

Question

I'm missing something. I used to use Mercurial and would look at the revision history of the repo with hg log. Simple: all changesets ever made in the repo are shown.

Now I'm using git. I'm pretty excited about learning the new tool, but I'm confused by what I'm seeing with git log. I've done some changes and made some commits. Another person has created a revision and committed as well. I pulled from his repository. I do a git log and his changeset (maybe it's called "commit" in git) isn't in the list. If I explicitly list his hash number (ie, git log <hash>), it shows up at the top. So it is in my repo, but I don't understand how git is deciding to show me what it does when I call git log.

I look at the git help log, but it says in the description that it "shows the commit logs." From my perspective, that's incorrect. Or perhaps incomplete because in reality it shows some subset of them. But I don't know what subset nor how it determines what to show.

Can someone explain git log to me?

Update

btw: One of the first things I had tried was --all, and I see now that many people suggest it. But that doesn't show it either:

$ git log | grep fb2a17c5fb08498e7f2ab364931fddc379be106f 
$ git log --all | grep fb2a17c5fb08498e7f2ab364931fddc379be106f 
$ git log fb2a17c5fb08498e7f2ab364931fddc379be106f  | grep fb2a17c5fb08498e7f2ab364931fddc379be106f 
commit fb2a17c5fb08498e7f2ab364931fddc379be106f

Answer 1

There is an implied argument to git log when you don't specify a reference or set of references. It is the current head. So

git log

expands to

git log HEAD

which means show me all the commits reachable from the current HEAD (where your next commit will attach).

In order to see your colleague's work, you can

git log origin/master

assuming you are both working on master and you fetched already.

In git, fetch means get the commits from the remote but don't update any of my local branches. git pull will do fetch and then merge your branch with what it fetched. It is a good idea to fetch, inspect what was done and then merge or rebase or even reject what was done with a force push - depends on the situation and your workflow.

typically, to see what was done on the remote after a fetch you can

git log ..origin/master

this really expands to

git log HEAD..origin/master

the .. operator is short hand for combining "exclude reachable commits from this reference" and "include reachable commits from this reference". So it could also be written like this:

git log ^HEAD origin/master

the ^ at the beginning of a reference means exclude the commits reachable from here. In this case it means what you have reachable from where you are. The result will be a list of the commits on this branch just fetched from the server.

Instead of listing all the branches and remote branches as arguments to git log, you can just use the --all parameter:

git log --all

which will show all commits reachable from all branches (local and remote tracking) and tags.

git log is a very powerful command due to how it allows you to do set based reductions of what commits you want to see. .. is a good syntax to know. There is also ... which says to include commits from both the branches specified down to their common ancestor.

This walking of history is what makes git so powerful and able to support so many interesting workflows.

UPDATE:

When git encounters commits that are identical in terms of what is contained in the tree stored there with it's parent, it will not list the commit when it walks a merge.

git log --all --sparse

will not exclude those commits.

see the history simplification section of http://linux.die.net/man/1/git-log

It could also mean that you reset a branch or your friend did and fetching again has lost that reference. When you do git log with the sha1, what is the output if you add --decorate to it? Also try git log --walk-reflogs.