How does git log work across branches?

Question

I'm using a github repository and it has a master branch and a demo branch. All was good and both the master version and the demo version of the code are in use (master on a staging site, and the demo on a demo site). A live site runs on a tagged commit.

While making changes, I messed something up which did not reveal itself for a while so I needed to start looking through old commits to see how I introduced the problem.

On Github I saw commits for the demo branch as follows:

Changed logos to xxx ones
8c4a3eab22 Browse code 
pwhipp authored 3 days ago
Feb 04, 2014
Paul Whipp
Changed archetype age_default to default to zero (and set all null va… …
6e4c9e8864 Browse code 
pwhipp authored a month ago
Feb 03, 2014
Paul Whipp
Added demo.xxx allowed domain for RED
2f72e3b05a Browse code 
pwhipp authored a month ago

So on a local repo, pulled up to date, I do "git checkout 8c4a3eab22". Then when I invoke git log locally, I see:

(red)~/wk/red $ git status
# HEAD detached at 8c4a3ea
(red)~/wk/red $ git log
commit 8c4a3eab22dc2ce9708c9aae00751e558ae81dd3
Author: pwhipp <paul.whipp@gmail.com>
Date:   Thu Feb 27 10:55:21 2014 +1000

    Changed logos to xxx ones

commit 2f72e3b05a005738d77ed12be475634aadf76b49
Author: pwhipp <paul.whipp@gmail.com>
Date:   Mon Feb 3 10:58:08 2014 +1000

    Added demo.xxx allowed domain for RED

Why is 6e4c9e8864 not shown by git log? It exists (I can check it out) but the differences between it and 8c4a3eab22 seem far greater than those indicated when I browse 6e4c9e8864 on github so I'm thinking there may be other commits I'm not seeing.

Do I need to RTFM somewhere to understand how the commits are being reported in the log call across the different branches?

Answer 1

Thanks to the comments and Conner's answer, I think I have this sorted:

In short, everything is correct but potentially confusing because of the difference between the chronological order of the commits and the order that merges have brought the commits into use in the demo branch. If you need to just list commits that represent valid states in your current branch you must use "git log --first-parent ....".

The long:

The current demo branch has been merged with master after 8c4 so 6e4 shows in its correct position in the log when looking at the full log history for the demo branch on github.

When I checkout the 8c4 locally, I'm looking at a demo branch state where 6e4 is NOT yet involved because the merge was after 8c4 so 6e4 does not appear in the log because 6e4 is only in the master branch (even though it was done after 2f7).

I can check 8c4 out because it is a state of the master branch. However, if I do, I am looking at a state of the master branch NOT the demo branch. There is no state of the demo branch where 8c4 was at the head of that branch.

The clearest and best picture for resolving this problem came from gitg (which is in the ubuntu repository "sudo apt-get install gitg" got it for me). Once I'd used that, I found the text output from "git log --oneline --graph" easier to understand).

This is only really confusing when you try to step back through a branch history. If you try to use "git log" you are seeing a list of the commits that affect your current code base but they are not necessarily states that existed in the branch you are on.

If, like me, you need to step back through each state in the life of your branch then (thanks to this question) you need to use the --first-parent parameter to git-log e.g.

(red)~/wk/red $ git log --first-parent --oneline
...
aa83af6 Merge branch 'master' into demo
...
8c4a3ea Changed logos to xxx ones
2f72e3b Added demo.xxx.com allowed domain for RED
...

Answer 2

It's difficult to say how the problem came into being without more information. However, a few points may help you diagnose it.

1. A commit can "exist" (be able to be checked out) without being a part of the branch's history. For example, if I have two diverging branches b and c which both have a common point a. If I'm in branch b I can still checkout commits that are unique to branch c without having to first check out that branch. You can use git reflog to get a full story of what has happened to the repository in the past. A branch is just a label for one of these points in git's history.
2. It's better to avoid git pull since it fetches and merges from the remote. In this case you may have merged into the wrong branch (e.g. merged remote master into local demo) which would could cause different results than you expected.
3. The commit may have been pushed to the remote and then later removed/squashed locally with a git reset or git rebase. In this fashion, it would show on github but not in your local repository.