On Fri, 2006-03-17 at 14:39, Junio C Hamano wrote: > > 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. > > 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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html