Re: git-reset and clones

On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:

You used to have something like this:


                 o---o---o---A
                /            ^ your HEAD used to point at here
    ---o---o---o

and you forgot other people already have the commit chain up to
commit A.   But you rewound and did cleanups:

                 o---o---o---A
                /
    ---o---o---o---o---o---B
                           ^ your HEAD now points at here

People who track your HEAD have A and your updated head B does
not fast forward.  Oops.

The recovery consists of two steps.  The first step is more
important.  To find what commits you lost that others already
may have.  You may be lucky and remember A's commit object name,
but when I did that I had to ask around on the list X-<.

The second step is a single command:

	$ git merge -s ours 'Graft the lost side branch back in' \
		HEAD A

where A is the object name of that commit.  On your current
branch, this creates a merge commit between A and B (your
current HEAD), taking the tree object from B.

                 o---o---o---A
                /             \
    ---o---o---o---o---o---B---M

Junio,

Can you explain a bit more why the "ours" strategy
comes into play here?  I _think_ I understand, but
I'd like to hear a bit more explanation, please.
How is this different from just merging in A directly?

You want to keep the contents of the cleaned-up HEAD, so that is
why you are taking the tree from B.

And the "ours" strategy effectively says, "Favor the B
side of things when pulling in the A parts", right?

  With this commit M, you are
telling the outside world that it is OK if they start from a
commit on the now-recovered side branch.

This is mystical to me.  How is the "A" (ie, side branch)
now in a "recovered" state?

Thanks,
jdl