emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Torsten Wagner <torsten.wagner@gmail.com>
To: emacs-orgmode@gnu.org
Subject: org-mode meets git a first proposal ?!
Date: Fri, 24 Jul 2009 12:32:52 +0900	[thread overview]
Message-ID: <200907241232.52729.torsten.wagner@googlemail.com> (raw)

Hi everybody,

first of all I'm new to org-mode and I'm new to that list. Please be patient 
with me if I come up with the same silly ideas as hundreds of people before 
me.

I tried to check the archive and didn't find something similar.

I just came into this "org-mode"-topic and since I'm somehow a geek (as maybe 
many around here) my brain directly filled up with some 
ideas and some "improvements". Since I have close to zero experience about 
writing emacs-lisp code I thought to search for a companions to maybe discuss 
and hopefully realize some of the ideas. 

The first thing which bothers me is the usage of links inside org-mode. Don't 
get me wrong, its by itself a really killer feature which I use more and more, 
However, some of my org-files e.g. my daily laboratory book grow and grow and 
it becomes hard to remember which files I should better not move or which stuff 
I should better not delete since I might break a valuable link within the org-
file.

Thus, first of all I thought I can maybe protect text-blocks within the org-file 
or within other org-files from being removed. Maybe I can build something up 
like a function check-valid-of-all-links, etc. 
Later on I thought all the external links, buffers like gnus, irc, files on my 
disk,,,, are not save as well... how could I make sure that I never break up 
my org-file ??? 

Even worse I might not break up the link by deleting a file but by change the 
contents over time. Please think about the following situation:
I have something like 
"... In the [graph] of the last results, a huge peak is observable due to 
measurement problems  for the following set-up parameters ...." 
in my org-file and then several month later in a stupid act I overwrite this 
file by some very similar but different results, e.g. because I was not longer 
aware of the link and thought there is no need to keep this old graph with the 
ugly peak and replace it by something "better". 
Now the link still depicts to a graph (lets say without or smaller peak) and 
back in org-mode I might reread my entries check what I did several months 
ago... and I will be very confused since the graph and the written text have 
some quirks (refer to a peak where no peak is depict in the graph and refers 
to wrong measurement parameters) my boss ask me what sort of mess I did,  
which I can not explain. He claims its the fault of all this "linux-hacker-
emacs-org-mode-work-only-on-text-files"-stuff blaims me to dead and force me 
switching back to use Outlook, MS Office and MS Windows for the rest of my 
life..... wooohhh that would be a sad story !!!!

Since I'm a big fan of git, I think the beneficial and really tied combination 
of emacs org-mode and git is a real benefit for everyone who uses org-mode. If 
one can create an easy way to let org-mode use a git repository, you can 
always make sure that nothing breaks even if you delete, move or modify 
external files. 

For that task org-mode need to do know several features.

* it need to be aware of git and its commands (the user should not be bothered 
with fetches and pushes and commits...)

* the link command series needs a special link-type e.g. "freeze-link" to link 
not only to a file but also to the version of that file (could e.g. look like 
that [link]@<date>). That means, if 
something is linked within the org-file or to another file resp. buffer, a commit 
and tag to git should be created automagically on-the-fly to freeze the actual 
state of the file resp. buffer and if this link is selected, git should 
temporary restore the old content and you will see the state of the file as it 
was when you created the link (properly with some infos that the content 
changed, was removed, etc. in the mean time). 

* to make sure that really any file can be linked and tracked, files should be 
copied inside a given git-repro (with a somehow unique name) if linked for the 
first time and a command should be available to detect (automatically) changes 
on the original file and create commits to the git to be up-to-date with 
external files. I know that's fare from being perfect, since you start to deal 
with two files. But unlike you create a really huge git repro to store 
everything in your home and work folders I can not see another way, how to 
keep track of external files without touching the way how and where they are 
stored. A intermediate solution would be the following scheme. 
Create a link will do: check if file is in git, if no, add file to git (maybe 
rename it by name_md5hashsum.ext to make it unique for a flat git repro) delete 
original file and create a symlink to the git aware file (probably just call it  
name.ext).
This method centralise all org-mode-linked external files and put them under 
git and still keep a pointer at the original position. However, this implies 
other drawbacks. If I reset my git repro back in time. The link will depict to 
an old version of the file as well. If go to copy that file at this moment, 
let's say to send it by email, I would copy an old version. 
As you can see this really needs some careful thinking how to do that, right. 

* provide some more commands to use the benefits of this system (e,g, org-
fetch-file-from-server, org-update-ext-files, etc.)


This combination of git and org-mode provides some nice benefits. 

First of all everything which org-mode is aware of is within a git-repro. That 
makes it highly portable. If you like to use your complete working environment 
(your org-files and all linked files)  on another computer a easy "git clone 
git://myfirstcomputer/org.git" will do the job never miss a file !!!! 
For sure, a little script within emacs might make it easier as well, just ask 
for the source address and destination and a few seconds to minutes later 
you will find your complete org-mode work-environment on the other machine.

Secondly, a backup becomes very easy and can be performed by many different 
methods.

E.g. A file server, possibly on the other side of the world, might just pop up 
periodically with a "git pull git://myworkmachine/org.git"

However, a local git clone to a usb-stick or even a copy of the complete git-
repro will work as well.

Finally, with combination of org-mode and git, people can not just track 
actual notes and files but also the age resp. time and changes of there org-
files.

This provides two methods. You can just conventionally (in the org-mode 
manner) archive parts of your org-file because you might need to use it again 
and you like to have them close to you. Or you simply delete parts which you 
don't need anymore and you can be generous with this, since the info is not 
lost and can be completely restored by git if necessary.

This keeps your org-file slime and still allows you to even grep infos several 
years old and deleted long time ago.
Thus you might like to delete all infos of an old (and finished) project and if 
2 years later someone ask you to perform a similar task... don't worry it is 
all still there, just "move back in time" and check for it

Finally, it might even allow a sort of collaboration via net and email. With 
git one can send patches by e-mail and one can fetch (cherry pick) patches 
over network. If someone creates an org-file "group-work.org" and teach org-
mode to create individual git commits for this special file. He can either send 
a patch to someone by e-mail and his colleague can apply this patch and see 
what was changed in the file or the colleauge frequently cherry-pick patches to 
that file and will receive all the changes over the net. Again both methods 
could be integrated in org-mode by a set of a few commands (e.g. org-team-
create, org-team-add-file, org-team-send, org-team-fetch, org-team-email, org-
team-apply-email,  etc.)

I would be happy if you could tell me your opinion about this ideas. All of 
these is just pop up of my mind and some points really need some sleep and 
some good discussion and reconsideration ... thus it is a very very first 
alpha-draft. I checked the web. Some people use git for there org-files (as I 
do). However, mostly we use org-mode and after things are done change to a 
console (or use a git-mode in emacs) and fiddle around with git commands. 
A good integration between both is still missing.

With best regards,

Totti

             reply	other threads:[~2009-07-24  3:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-24  3:32 Torsten Wagner [this message]
2009-07-24  5:18 ` org-mode meets git a first proposal ?! Matthew Lundin
2009-07-24 13:17   ` Jason F. McBrayer
2009-07-24 15:35     ` Torsten Wagner
2009-07-24 15:32   ` Torsten Wagner
2009-07-26 20:40 ` Bastien
2009-08-03  4:39   ` Carsten Dominik

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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200907241232.52729.torsten.wagner@googlemail.com \
    --to=torsten.wagner@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 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).