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
