From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Young Subject: [GSoC] Merge Driver progress and conflict markers Date: Fri, 13 Jul 2012 14:03:24 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:37547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpkDD-0004IN-C2 for emacs-orgmode@gnu.org; Fri, 13 Jul 2012 14:03:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpkD8-00042J-Cz for emacs-orgmode@gnu.org; Fri, 13 Jul 2012 14:03:31 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:58435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpkD8-00042C-5Y for emacs-orgmode@gnu.org; Fri, 13 Jul 2012 14:03:26 -0400 Received: by wibhm2 with SMTP id hm2so731974wib.0 for ; Fri, 13 Jul 2012 11:03:24 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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