Re: git-reset and clones

[Andreas Ericsson <ae@op5.se>]

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

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

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