RE: git -- how to revert build to as-originally-cloned?

From: George Spelvin <linux@horizon.com>
Date: May 20, 2011, 16:25 UTC
Message-ID: <20110520162502.7854.qmail@science.horizon.com>

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.