Post by zookoSome tools, such as arch, can track
"which file" precisely, but use a 3-merge for "which lines", which
means they cannot answer the "which lines" question without
guessing. Others, such as darcs, track 'which lines" precisely.
I don't why you think Arch "cannot" do what Darcs does.
If you really wanted Darcs-style merging for Arch, you
could probably implement it without modifying Arch at
all in a mix of sh(1) and awk(1) -- at least to get it started.
Arch's "database" conveniently contains all of the information
you need to run the Darcs merge algorithm.
Also: Arch *has* a 3-way merge built-in but it also has other
kinds of merge and, as I suggest above, you can add more if you
like without having to modify Arch itself at all.
Post by zookoObviously I, and everyone else, know that "merge produces a better C
program" is not a property that we are going to directly achieve by
tweaking our resolution and location algorithms. It is a very
important property, and we should think about how to facilitate users
to achieve it, but it arises only from the interaction of algorithm
and user -- not from algorithm alone.
That's all crazy talk, imo. The purpose of a merge algorithm
is to help make an integration process more efficient. Automatically
changing lots of lines in many files can speed up editing, but
the output shouldn't be a "better C program" but "a better state
of the source tree from an integrator's perspective".
For example, here is a merge feature I'd like to see:
Let's let patches be optionally *signed*.
Let every source tree contain a policy file, mapping
files and directories in the tree to various merging
policies and public keys. The policies might say
"only certain signers can modify certain files -- if
others try to, treat that as a merge conflict." Or,
the policies might say: "Permit any merge to modify
the file scheduler.c, but put conflict markers around
every change made, even if there is no conflict" (thus
forcing a by-hand review of changes to scheduler.c).
Those examples illustrate that the quality of a merge tool,
for some users at least, may not have as much to do with
the semantics-in-C of the output of the merge.
Post by zookouncertain assertion 5. Correctly answering both the resolution and
location questions is necessary and sufficient for "applying the
patch the way the user intended".
That is false. Diffing, patching, and merging tools are
inevitably imprecise, heuristic instruments. They will always
have pathological cases that are common enough to arise
accidentally, in practice, at measurable-enough-to-worry-about
rates. No cleverness in merge algorithm design is going to change
any of that, ever.
This is a topic that often seems to get confused hackers talking
in circles because it gives rise to an accidental game. Programmer
A proposes merge algorithm X. Programmer B finds the
pathological cases in X. A proposes X'. B finds the X' problems.
Lather, rinse, repeat: this is apparently where much of the discourse
around open source revision control projects has stood pat since,
perhaps, 2002 or so. The punch line is that it's a shaggy dog story.
There is not X'''..'''' which fixes all the problems. A different *kind*
of solution is needed.
That other kind of solution is the "shop tools" approach. No
merge algorithm will always DTRT and the pathologies of every
known tool are significant. So, the solution is to make it easy to
not overlook the pathologies when they occur, and to have a variety
of specialized tools so that, when pathologies occur using one tool,
perhaps there is another tool to do the job instead. A variety of
tools -- hard to miss when pathologies happen -- easy to review what
a tool has just done. A very different problem from "produce a
better C program".
And this gets back to your "uncertain (5)": user intention.
If integrators are using shop tools, then when I thoughtfully
submit a "patch" I must be offering some raw materials (fragments
of new code) and a "construction plan" that tells how to use
those raw materials, plus tools, to make a modification to
the integrator's very own version of the program.
"Construction plans" as exchanged between more traditional
shops (such as wood shops) are human-to-human communication
of imprecise formulae. Perhaps my submitted plan describes
the construction of a 36" cabinet but you need a 24" cabinet.
Perhaps the plan calls for a bar clamp but you have something
else in mind. A good construction plan is then one that is lucid
enough for you to work with as you adapt it to your situation,
using the tools and materials you have at hand. When I submit
my patch, *that* is my intention: to give you a "workable" plan,
not a perfect one.
By definition, a "construction plan" can not be automatically
applied. Human judgment is called for to interpret and adapt
the plan. A merge tool "conforms to user intention" if both
the submitter and integrator agree about how, generally, it
will behave when manipulated with various standard tools
kept within nominal operating conditions.
In other words, the best way to be faithful to user intention is
first to build tools that behave unsurprisingly and, second, tools
that help software craftspeople efficiently exchange and manipulate
construction plans, each plan giving a description of how one revision
of a program can be changed into another.
-t