On Fri, Nov 13, 2015 at 6:14 PM, <to...@acm.org> wrote: > The following Windows batch file will reproduce the condition I’m talking > about (f = fossil): > ------------------------ > f new sample.fossil > f o sample.fossil > echo Hello > hello.txt > f add hello.txt > f com -m Initial > echo Hello, World > hello.txt > f com --branch other -m "Added World!" > echo Computer said: Hello, World > hello.txt > f com -m "Added 'Computer said'" > f up trunk > f me other --cherrypick >
Thanks for this. It made it easy for me to visualize what is going on -- and no debugging was necessary! :) While the marked up hello.txt (with BEGIN MERGE CONFLICT / END MERGE CONFLICT lines shown) does not directly reveal the identity of the artifacts used to get the individual lines, the fact that this repository only has three commits (excluding the empty initial commit that is irrelevant) of single line files makes it easy. Additionally, when there is a merge conflict, fossil creates filename-baseline, filename-merge, and filename-original files that show us exactly which file is which. The common ancestor is "Hello, World" (from the second commit, aka the first commit on branch other). In reality this is a misnomer based on what we would consider an ancestor, because it is not an "ancestor" of trunk. More accurately it is called a baseline in a three way merge (as it is in the hello.txt-baseline file). The local copy is "Hello" from the tip of trunk. The merged in copy is "Computer said: Hello, World" from the tip of other. In a normal (non cherrypicked) merge, the common ancestor would be the tip of trunk. The local copy and common ancestor would be the same. Regardless of normal or cherrypicked merge, the simplified process is as follows: Compute the set of diffs from common ancestor to local copy. Call it A. Compute the set of diffs from common ancestor to merged in copy. Call it B. For each member b of B (consisting of a block of lines from line x to line y): Is there a member a of A (consisting of a block of lines from line t to line u) that overlaps with b? No, merge it into the local copy. Yes, there is a merge conflict. Given our baseline, local, and merged in files: A: [1-1] (line 1 'changed' from "Hello, World" to "Hello") B: [1-1] (line 1 'changed' from "Hello, World" to "Computer said: Hello, World") The two blocks overlap completely with one another, so the line based three way merge doesn't know which line to take. The difference between the normal vs cherrypicked merge is the selection of the baseline: In a normal merge, you find the nearest common ancestor and use it as the baseline. In a cherrypick merge, you use the parent of the to be merged commit as the baseline. And that is why in your case, the fact that "SRF_OUT" was never referenced in trunk was confusing. It was not in the trunk, but was in the baseline, which was not strictly speaking a common ancestor, but the terminology used was inaccurate / confusing for a cherrypick merge. I hope that explanation makes sense. Perhaps it would make sense to modify the "common ancestor" line in the marked up merge file to call it the baseline? Or "BASELINE (often known as COMMON ANCESTOR)"? Or something along those lines... -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users