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

["George Spelvin" <linux@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)

> 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.


> 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.