Ah - I should have said that I selected only merges in my git log command - git log --merges (With no qualifier, git log returns about 3.8 million lines / 150 MBytes, hard to work with)
Show 7 quoted lines
> And, based on what the command now returns, it seems that the first two > that I listed before (which are no longer present) were as a result of my > (single) merge command, i.e. my merge resulted in merging : > . two merges that were done by someone else in the master that I > cloned into my /b filesystem, > . maybe some other non-merge commits that I did not query before > and now don't know
Er, no. One "git merge" command produces (at most) one commit. It may be that the head of the branch you merged in was already a merge commit, but tha
You may find "gitk" useful for for visualizing all of this.
Show 8 quoted lines
> You've lost me here. If a merge can consist of many commits, > including other merges (see above), then how can one commit be a merge? > Note that in my original git log --merges output that I posted in my > earlier post, i.e. the one before I reset, there was *no* record of *my* > merge command itself, only of the sub-merges that my merge dragged along. > I think this is the crucial (to me) point - git did not record what I did, > only the effects of what I did. Not saying this is wrong or right, > but significant.
Okay, here's the basic confusion. Commits have pointers to other commits, and are organized into a linked list. (Actually, a directed acyclic graph, since a commit can have more than one ancestor pointer.) Thus, a commit identifies *both* a single snapshot *and* a complete development history. We tend to talk about a "commit" when describing the former, and "branch" when talking about the latter, but they're actually the same object.
A merge *is* exactly one commit. A "merge commit" is just a commit with more than one ancestor. Now, that merge can *point to* lots of other commits, but it doesn't exactly "consist of" them.
The other thing is that the ancestors of a merge are symmetrical. They are numbered for reference, but the practical results of "merge A with B" and "merge B with A" are identical. Every commit points to the full development history that produced it.
Now, what might have happened to you was a "fast forward" merge. If you have a history like this:
o--o--o--a--b--c--d
And you ask git to merge a and d together, the result will be simply d. Git, by default, avoids creating useless merges in such a case. So if you merge in someone else's work, and you haven't done anything locally since their branch split off from your HEAD, the result will not include a merge commit at all. (A NEW merge commit; they branch might include merge commits.)
Since the top merges in your example are by Dave Miller (and not by you), it looks like that's what happened in this case.