[O] [GSoC] Merge Driver progress and conflict markers

[Andrew Young]

Hello list,
Another small progress update on the org-merge-driver:

The merge driver at this point has the ability to detect the insertion
and deletion of headings, and should correctly cause updates to the tree
structure to conflict.

Here is a short example of the merge driver at work:

Ancestor File:

* Gardening
** Spring Planting
* Rocket Cars
** Speed Concerns
*** How to go faster
* Origami
- How do you fold a crane?

Local Revision:

* Gardening
- Buy a sprinkler.
* Rocket Cars
- rocket cars are cool.
** Speed Concerns
- I'm not going fast enough.
*** How to go faster
*** Bigger engines

Remote Revision:

* Gardening
** Spring Planting
* Rocket Cars
- rocket cars are dangerous.
** Safety Concerns
- Look into wearing a helmet.
* Origami
- Cranes are easy.

Output File:

* Gardening
- Buy a sprinkler.
* Rocket Cars
>>>
- rocket cars are cool.
===
- rocket cars are dangerous.
<<<
** Safety Concerns
- Look into wearing a helmet.
>>>
** Speed Concerns
- I'm not going fast enough.
*** Bigger engines
===
<<<
>>>
===
* Origami
- Cranes are easy.
<<<

Currently, I am working on global matching, which is my name for
detecting element's movement across the document.

I need some input on the display of conflicts: Right now I am trying
to devise the output to be as informative and useful as possible.

There are a number of issues to consider:

1. Providing the most amount of information possible.  This means
including descriptive information in the conflict markers, and never
combining the conflict markers of side-by-side conflicts.  There is
also a risk of printing too much, and cluttering the output.

2. Nested conflict markers. With global matching implemented in the
near future, the merge driver may be printing nested conflicts. This
is because it is possible for conflicts to be inside other conflict
boundaries.  It will be important to consider the desired behavior and
output of the merge driver when merging elements whose parents have
conflicted.

3. Compatibility with org-mode and traditional diff tools. Some merge
tools may simply fail with nested conflicts.

4. Visual queues.  Nested conflict markers could be indented according
to their conflict level to help see where they line up.  This has the
trade off of abandoning the traditional style, and may be initially
confusing.

Following is a simplified example of nested conflict markers. In the
example, each heading is unique and we assume their movement may be
tracked.  In the actual merge driver, IDs would be used to implement
tracking of this nature.

EXAMPLE 2

Ancestor:

* Heading 1
* Heading 2
* Heading 3
** Heading A
** heading B

Local Revision:

* Heading 1
** DONE Heading A
** Heading B
* Heading 2
* Heading 3

Remote Revision:

* Heading 2
** TODO Heading A
* Heading 3

Output File:

>>> local: updated children
* Heading 1
  >>> local: content update
** DONE Heading A
  ===
** TODO Heading A
  <<< remote: content update
** Heading B
===
<<< remote: deleted
* Heading 2
>>> local: moved
===
  >>> local: content update
** DONE Heading A
  ===
** TODO Heading A
  <<< remote: content update
<<< remote: moved
* Heading 3

## output, non-nested conflicts
>>> local
* Heading 1
** DONE Heading A
** Heading B
===
<<< remote
* Heading 2
>>> local: moved
===
** TODO Heading A
<<<
* Heading 3

For the moment, I am partial to using nested conflict markers. Nested
markers display as much information as possible, and allow the merger
to do as much work as possible towards merging the final document.
The drawback of nested markers is that they may be a major departure
from diff output.

Any kind of brainstorming, interesting examples, or opinions would be
a huge help to me.

Thanks,

Andrew