Re: git-reset and clones

From: Jon Loeliger <jdl@freescale.com>
Date: Mar 17, 2006, 21:00 UTC
Message-ID: <1142629202.17536.242.camel@cashmere.sps.mot.com>
In-Reply-To: <7vslpgztzc.fsf@assigned-by-dhcp.cox.net>

On Fri, 2006-03-17 at 14:39, Junio C Hamano wrote:

Show 6 quoted lines

> > And the "ours" strategy effectively says, "Favor the B
> > side of things when pulling in the A parts", right?
> 
> Yes, it is stronger than that.  "ours" says: "the tree from our
> head commit B *is* the resulting tree -- whatever we are merging
> into us does not matter".

Aha!  This all makes much more sense now suddenly.

Thank you.

Show 15 quoted lines

> 
>                   o---o---o---A---N
>                  /               /  
>      ---o---o---o---o---o---B---'
> 
> Because the forked track leading to B was either to fix mistakes
> or clean things up the upstream originally did in the track
> leading to A, the commits on the tracks leading to A and B from
> their fork point are almost guaranteed to have conflicting
> changes, and resolution of that conflict is forced on the
> downstream person.  Worse yet, from this point on, since the
> upstream discarded the track that contains A, the branch
> downstream person has will _never_ converge to upstream branch,
> even though the downstream person did _no_ development of his
> own in the meantime.  This is *B*A*D*.

Wow.  Yeah.  Bad.

> If there is a magic "ours" merge, the downstream person's
> repository records A as the last tip on the tracking branch, and
> git-fetch sees the updated head M is a descendant of it, so it
> simply fast-forwards:

That's beautiful. I get it. This has been an extraordinarily helpful explanation (for me)!

Thank you!

jdl