As I've been working on a fairly large Org outline over the past few days, I've discovered that the format is very ill-suited to management and review by (known) version control tools, like Git. Indentation is always changing and volatile information like tags and priorities tends to mix with headlines, which makes diffs very hard to track. This is to say nothing of the fact that diff itself is a poor format for understanding changes that simply reorganize parts of documents. I was wondering what other people do. I want to make sure I understand the changes I'm making to my document and that I haven't unintentionally wiped out a great deal of important material (all the more likely to happen without me noticing because of Org's folding). Hints most appreciated, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams <dave@boostpro.com> writes:
> As I've been working on a fairly large Org outline over the past few
> days, I've discovered that the format is very ill-suited to management
> and review by (known) version control tools, like Git. Indentation is
> always changing and volatile information like tags and priorities
> tends to mix with headlines, which makes diffs very hard to track. This
> is to say nothing of the fact that diff itself is a poor format for
> understanding changes that simply reorganize parts of documents.
>
> I was wondering what other people do. I want to make sure I understand
> the changes I'm making to my document and that I haven't unintentionally
> wiped out a great deal of important material (all the more likely to
> happen without me noticing because of Org's folding).
>
> Hints most appreciated,
The main thing I do is use org-indent-mode so indentation is not a
factor in the diffs. Everything starts at column 1 and moving things
around and promoting headlines doesn't change the indent of the items.
I also use 'git log --stat' to get a quick overview of my hourly commits
to reassure myself that large parts of the document didn't get removed
by accident. I normally only do this after archiving (which is monthly)
but this also makes is relatively easy to identify a commit where a
large block of content was removed in the event I want to restore the
old content.
I rarely have to resort to my git history to restore something (maybe 2
times a year?) but I really like the safety net of my hourly git commits
on my org-files so I can be confident I won't permanently lose anything
which is important to me.
HTH,
Bernt
>> Hints most appreciated, > > The main thing I do is use org-indent-mode so indentation is not a > factor in the diffs. Everything starts at column 1 and moving things > around and promoting headlines doesn't change the indent of the items. > I also always start my subtree content at column 1 (I never indent whole section bodies) and I think this helps promote saner diffs and generally encourages better Org-mode behavior. Additionally you could try the --word-diff option to git, i.e., git diff --word-diff or git diff --word-diff=color which returns diffs which ignore whitespace changes and which show changes on the word rather than line level. I believe it is possible to make this behavior default for a git repository but I've never done so and don't know how such a default would be specified. Hope this helps -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Eric Schulte <schulte.eric <at> gmail.com> writes: > Additionally you could try the --word-diff option to git, i.e., > > git diff --word-diff > > or > > git diff --word-diff=color > > which returns diffs which ignore whitespace changes and which show > changes on the word rather than line level. I believe it is possible to > make this behavior default for a git repository but I've never done so > and don't know how such a default would be specified. > > Hope this helps -- Eric > Thanks for the tip. Here's some info that I think shows how to make --word-diff option the default for a particular type (e.g., .org) fie: http://stackoverflow.com/questions/7542543/use-gits-word-diff-for-latex-files -- Herb
[-- Attachment #1: Type: text/plain, Size: 109 bytes --] I wonder how much is involved in using the generic org parser (which one I am not sure) to hook into ediff?? [-- Attachment #2: Type: text/html, Size: 113 bytes --]
On Mon, Oct 17, 2011 at 8:55 AM, Rustom Mody <rustompmody@gmail.com> wrote: > I wonder how much is involved in using the generic org parser (which one I > am not sure) to hook into ediff?? I believe you mean something like this[1] discussion? That thread wasn't particularly conclusive. [1] <http://thread.gmane.org/gmane.emacs.orgmode/45781/focus=45941> -- Suvayu Open source is the future. It sets us free.
* Dave Abrahams <dave@boostpro.com> wrote: > > I was wondering what other people do. I am using http://www.mayrhofer.eu.org/dvcs-autosync for automatically committing of changes but without activated XMPP sync feature (so far). The already mentioned «git diff --color-words» helps me a lot when examining my git history. -- Karl Voit
[-- Attachment #1: Type: text/plain, Size: 872 bytes --] > > Dave Abrahams <dave <at> boostpro.com> wrote: > > > > I was wondering what other people do. > > I am using http://www.mayrhofer.eu.org/dvcs-autosync for > automatically committing of changes but without activated XMPP sync > feature (so far). > > The already mentioned «git diff --color-words» helps me a lot when > examining my git history. > > -- > Karl Voit > dvcs-autosync is an interesting project The OPs question IIUC is orthogonal to it. The problem as I see it is that org mode docs are two things: -- they are text mode data (when in emacs mode) -- hierarchical data (when in org-specific mode) Diff unfortunately does not understand the hierarchical view. I tried to see if xmldiff will run And if it did then try pipe the output of org-docbook-export to it. Unfortunately my attempts at getting xmldiff to run did not work [-- Attachment #2: Type: text/html, Size: 1176 bytes --]