[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Git merge tool for Org files

From: Nick Dokos
Subject: Re: [O] Git merge tool for Org files
Date: Sat, 20 Aug 2011 12:04:20 -0400

Andrea Crotti <address@hidden> wrote:

> On 08/18/2011 12:45 PM, Carsten Dominik wrote:
> > Hi,
> >
> > I was wondering if anyone here has the skills and interest to write
> > a git merge driver for Org mode files, in the way
> >
> >     
> > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
> >
> > does this for GNU style ChangeLog files?
> >
> > One of the obstacle for using Org-mode for collaborative programs is that
> > many operations add or remove text from the beginning or end of a file,
> > or which add or remove a subnode from an outline tree.
> > These are operations that confuse the git merger, in particular
> > if two people have added something to a file, or removed/added
> > sequential sibling nodes.
> >
> > I believe that this could be solved with a dedicated merge driver
> > that understands the integrity of an outline (sub)tree, and that
> > knows that the sequence of two new subtrees added by different people
> > does not matter.
> >
> > The idea for this is actually (I believe) from Brian Gough who asked me
> > about it at FOSDEM.  I have now also run into this problem and would
> > really find it great if such a merge driver could be written.
> > Unfortunately, I do not have the skill for this.
> >
> > - Carsten
> Does the merge driver need to be written in C?
> It looks quite a complex task considering that org-mode files
> are not so easy to parse...


> On 08/20/2011 04:42 PM, Carsten Dominik wrote:
> > I have no idea, but I would think that it could also be written in Perl,
> > for example.
> >
> Yes from what I understand from the source it can be any executable
> that outputs things as git expects them.
> There are no compile time dependencies on git as far as I see.
> So maybe why not writing it (even a prototype) directly in Elisp?
> That would solve many things right?

Perhaps a better way is to not insist on automatic conflict resolution
(changelogs are relatively simple, whereas org files would be more
complicated: one would have to impose lots of rules to make sure that
the merge would be successful). A relatively painless manual,
interactive merge might fit the bill better.

In his book "Pro Git"[fn:1], Scott Chacon describes how to hook an
external merge tool into git (he uses the -free- Perforce Visual Merge
Tool for illustration, but it should be possible to use anything).  And
emacs has the emerge tool already built in.  In fact, Chacon mentions
emerge as one of the presets in git, so it may be even simpler than what
he describes.

This is all theory and we all know that [fn:2] "In theory, there is no
difference between theory and practice - in practice, there is."  But it
seems worth investigating this a bit, before striking off into an
unknown unknown. [fn:3]



[fn:1] Available on the web at http://progit.org/book, as well as on
paper (see the website for details). Section 7.1 is the relevant part.

[fn:2] ...in the words of that immortal philosopher, Yogi Berra, ...

[fn:3] OK, ok - Donald Rumsfeld said the "unknown unknown" thing first.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]