For commit hashes A, and B, I was slightly confused. I expected these to be part of the master branch. Commit A has a commit date a few hours later than commit B, but when I ran git log --pretty=fuller A I can't see B in the history (I scroll well past commits with earlier commit dates than B's). For a sanity check, I ran git log --pretty=fuller B and I didn't see commit A in its log history.
I'm using the --pretty=fuller flag because commits seem to be ordered by their commit data, not their author date, so I thought this would be a better way of comparing their positions in the history.
At this point I thought one of the commits must be on a different branch, so then I ran:
git merge-base master A this returned A
git merge-base master B this returned B
So to me this said that they're both on master, which means one of them should belong in the log of the other. [conclusion 1]
At this stage I thought I might be missing a flag to shall all commits in the log, so I thought I'd run another command as a reality-check:
git merge-base A B this returned yet another commit (which we'll call C)!
Now this implies to me that one is not the ancestor of the other, which seems to contradict conclusion 1!
Could someone please point out where my reasoning is wrong here? I'm neck-deep in commit logs at the moment and this has really got me stumped. Thanks.
As Jeff Bowman pointed out in comments, my conclusion 1 was wrong.
The relevant issue is in the case of a merge.
I mistook what happens to a branch on merge: I'd assumed that when a branch is merged into master that that branch is not part of the log history of master - that only the merge commit/s would show. This is not the case.
In the end, commit A was on a branch that had been merged with master, and commit B had occurred after the initial branching, but before the merge commit.
As I wanted to be able to search through only the "main" master branch without looking at the feature branches, it seems that using the flag git log --first-parent helps do just that.