emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [GSoC] Merge Driver progress and conflict markers
@ 2012-07-13 18:03 Andrew Young
  0 siblings, 0 replies; only message in thread
From: Andrew Young @ 2012-07-13 18:03 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-07-13 18:03 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-13 18:03 [GSoC] Merge Driver progress and conflict markers Andrew Young

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).