Re: git-reset and clones

From: Andreas Ericsson <ae@op5.se>
Date: Mar 17, 2006, 21:21 UTC
Message-ID: <441B2865.5090505@op5.se>
In-Reply-To: <1142623141.17536.225.camel@cashmere.sps.mot.com>

I'm in sort of shallow waters, hoping that Junio or Linus will come along and pull me off the shores in case I mis-step and say something stupid that would have made an amusing pictograph had it been done right by a cartoonist.

Jon Loeliger wrote:

Show 47 quoted lines

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

"Ours" is an algorithm you can invent yourself and pass as the defautl merge strategy (useful if you know you'll always keep upstream as-is or some such).

Show 8 quoted lines

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

Yes, and/or no. "Ours"' is still whatever you want it to be. Perhaps we should add some new strategies, like "favour-current" and "favour-new".

Show 9 quoted lines

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

Because the commits pullers already have are now inside the respository history, as seen by average pullers (again). The merge between "master" (or some such) and "new-devel" (or some such) happen to coincide, which means they share a mutual merge-base, which means they're both part of the same chain of developemnt. If you intend to disimiss most of the changes between (fork-point) and (point-of-new-weird-rebase) this might not be the best solution, but...

Sorry, but to me this is friaday night and currently I can't logically differ between a bluewhale and a kangaroo [*1]

/exon

[1] Sadly, this has been empirically proven. [*2]

[2] At some other time. I'm no *that* drunk right now.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231