From: Nick Dokos <nicholas.dokos@hp.com>
To: Andrea Crotti <andrea.crotti.0@gmail.com>
Cc: Brian Gough <bjg@network-theory.co.uk>,
Org Mode List <emacs-orgmode@gnu.org>,
nicholas.dokos@hp.com,
Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: Git merge tool for Org files
Date: Sat, 20 Aug 2011 12:04:20 -0400 [thread overview]
Message-ID: <23368.1313856260@alphaville.dokosmarshall.org> (raw)
In-Reply-To: Message from Andrea Crotti <andrea.crotti.0@gmail.com> of "Sat, 20 Aug 2011 16:17:51 +0200." <4E4FC20F.7090101@gmail.com>
Andrea Crotti <andrea.crotti.0@gmail.com> 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...
>
and
> 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]
Nick
Footnotes:
[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.
next prev parent reply other threads:[~2011-08-20 16:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 10:45 Git merge tool for Org files Carsten Dominik
2011-08-20 14:17 ` Andrea Crotti
2011-08-20 14:42 ` Carsten Dominik
2011-08-20 14:56 ` Andrea Crotti
2011-08-20 16:04 ` Nick Dokos [this message]
2011-08-20 17:30 ` suvayu ali
2011-08-20 19:08 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23368.1313856260@alphaville.dokosmarshall.org \
--to=nicholas.dokos@hp.com \
--cc=andrea.crotti.0@gmail.com \
--cc=bjg@network-theory.co.uk \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.