On 2009-01-30, Raimund Berger <raimund.berger@xxxxxxxxx> wrote: > E.g. with A, B and ancestor C, the merging and conflict resolution > algorithm had to be completely symmetric if diff(A,C)+diff(B,C) applied > to C should always be the same as diff(B,C)+diff(A,C) applied to C. > So I'm really asking if that is a fact upon which I can rely. I've always relied on it :-) Or, to put it another way, I've never come been bitten by this issue. > An interesting hint. Up to now, I assumed that rebase would always > perform implicit merging strategies. I mean what else would one expect It does. > in the above picture to happen when rebasing A on B? I'd assume it'd > produce the same tree as a merge of A into B, by employing exactly the > same machinery. E.g. fast forward of C to B, then merge A in. So that, > effectively, the only difference between rebase and merge is just commit > history but not (tree) content. This is also true. For example, "git help pull" offers an option to use rebase instead of merge. > From reading the rebase man page though it seems that merging machinery > has to be explicitly requested via '-m'. Which makes me wonder how the > default rebase actually works. No. I think the documentation is not sufficiently clear. Everything else in "git help rebase" (look for the string "strateg") tells me that the default, if you don't specify anything at all, is the recursive merge strategy. Since "-s" implies "-m", I'm not sure what -- if anything -- is achived by "-m" all by itself. When I get some time I'm planning to look at the test scripts and simulate them without "-m" to see what differences there are; I'd assume a test script set up to test the proper operation of rebase --merge should be using a test case whose result differs if you dont use --merge! > Mathematically speaking, if A1 and A2 commute with regard to a binary > operation, A1 ... An do as well. So I'd still think the latter question > boils down to the commutativity question above *iff* rebase actually > does an implicit merge by default. Which I'm now led to question. Rebase *does* do an implicit merge by default (as far as the tree that results is concerned, which you mentioned right at the start), I'm pretty sure of it. Perhaps someone with more git smarts will chip in with something more concrete. -- To unsubscribe from this list: 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
