emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* org-mode meets git a first proposal ?!
@ 2009-07-24  3:32 Torsten Wagner
  2009-07-24  5:18 ` Matthew Lundin
  2009-07-26 20:40 ` Bastien
  0 siblings, 2 replies; 7+ messages in thread
From: Torsten Wagner @ 2009-07-24  3:32 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: org-mode meets git a first proposal ?!
  2009-07-24  3:32 org-mode meets git a first proposal ?! Torsten Wagner
@ 2009-07-24  5:18 ` Matthew Lundin
  2009-07-24 13:17   ` Jason F. McBrayer
  2009-07-24 15:32   ` Torsten Wagner
  2009-07-26 20:40 ` Bastien
  1 sibling, 2 replies; 7+ messages in thread
From: Matthew Lundin @ 2009-07-24  5:18 UTC (permalink / raw)
  To: Torsten Wagner; +Cc: emacs-orgmode

Torsten Wagner <torsten.wagner@gmail.com> writes:

[...]

> 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.

Though I can't address your idea of creating links to git revisions (I
believe this idea was discussed here recently), you might want to check
out org-attach.el as a way of pulling all relevant files into a git
repo.

Org attach can "attach" files to headlines by giving them a universal id
and depositing them (or a link to them) in a directory of your choice
(see the variable "org-attach-directory"). If the attachment directory
contains is controlled by git, org-attach will automatically check them
into the repo. So perhaps org-attach is already part of the way towards
the solution you're looking for.

> 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.

I can't say that this statement matches my own experience. I find emacs
and git integration to be superb. Any time I'm working intensively on
one of my org-files, I simply use vc-next-action (C-x v v) to check in
recent changes. Also I make heavy use of vc-log, vc-annotate, vc-diff,
etc. to survey changes to a file.

I also highly recommend magit. It makes it very easy to manage all
recent uncommitted changes to a git repo. Thanks to magit and vc-git, I
almost never use the command line managing git repositories. In fact,
I've come to see magit as an essential part of my work process -- i.e.,
as a way of reviewing and logging things I've worked on recently
(usually every hour or so).

That said, I think it would be nice to be able to create links to
particular git commits. 

Best,
Matt

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Re: org-mode meets git a first proposal ?!
  2009-07-24  5:18 ` Matthew Lundin
@ 2009-07-24 13:17   ` Jason F. McBrayer
  2009-07-24 15:35     ` Torsten Wagner
  2009-07-24 15:32   ` Torsten Wagner
  1 sibling, 1 reply; 7+ messages in thread
From: Jason F. McBrayer @ 2009-07-24 13:17 UTC (permalink / raw)
  To: emacs-orgmode

Matthew Lundin <mdl@imapmail.org> writes:

> That said, I think it would be nice to be able to create links to
> particular git commits. 

Yes, I think that's 80% of the benefit of this idea for 20% of the
work.   It might be generalizable to, to say when creating a file link
that if the file is under version control, to have a simple link syntax
for specifying a revision, and make it simple to specify the revision
that was active when the link was made.

-- 
+-----------------------------------------------------------+  
| Jason F. McBrayer                    jmcbray@carcosa.net  |  
| If someone conquers a thousand times a thousand others in |  
| battle, and someone else conquers himself, the latter one |  
| is the greatest of all conquerors.  --- The Dhammapada    |  

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: org-mode meets git a first proposal ?!
  2009-07-24  5:18 ` Matthew Lundin
  2009-07-24 13:17   ` Jason F. McBrayer
@ 2009-07-24 15:32   ` Torsten Wagner
  1 sibling, 0 replies; 7+ messages in thread
From: Torsten Wagner @ 2009-07-24 15:32 UTC (permalink / raw)
  To: Matthew Lundin; +Cc: emacs-orgmode


[-- Attachment #1.1: Type: text/plain, Size: 3530 bytes --]

2009/7/24 Matthew Lundin <mdl@imapmail.org>

> Torsten Wagner <torsten.wagner@gmail.com> writes:
>
> [...]
>
> > 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.
>
> Though I can't address your idea of creating links to git revisions (I
> believe this idea was discussed here recently), you might want to check
> out org-attach.el as a way of pulling all relevant files into a git
> repo.
>
>
Thanks Matt to guide me to org-attach.el. You are right it might cover great
parts of what I was looking to do.
I will try it and see how fare it fits

one of my org-files, I simply use vc-next-action (C-x v v) to check in
> recent changes. Also I make heavy use of vc-log, vc-annotate, vc-diff,
> etc. to survey changes to a file.
>
> I also highly recommend magit. It makes it very easy to manage all
> recent uncommitted changes to a git repo. Thanks to magit and vc-git, I
>

I use a git-mode too. Unfortunately it seems there are several concurrent
git-mode implementations available.
I will check out for vc and magit... overall it look like maybe great
portions of "my" idea are realised in one or the other form already.
Maybe there is only some more glue necessary to bind all this together to
make it even more easy to use it directly in org-mode ?!


> That said, I think it would be nice to be able to create links to
> particular git commits.


In my post I thought I like to give a picture of what might be all possible
by combining git and org-mode. However my initial idea was to preserve
links.
Thus, I have no problem to synthesis the idea to a much more clean and
foccused point of having  *frozen-links*.

If I link to a file which is part of a git-repro (maybe added by
org-attach.el) I would like to have the option to tag the git-repro and
visit the state of the git-repro at the time the link was created. A link
might look like [the link]@<the date> or [the link]@"first commit line"   to
indicate that this is a "frozen" link in a git system, different colours
might indicate whehter the content changed already over time.

I think only this new feature might be able to introduce org-mode as a very
nice tool the managment of programming projects. All programmers of an
project can beside of the source code keep org-files for more verbose
description and ideas with plenty links to the source code itself and the
frozen links make sure that the thinks they refer to never become wrong or
obsolete.

In general, I just realised that org-mode might be an nice solution for
programming project managment. Starting from writing up your requirement
specification, discussion and explaination among the dev-team as well as the
documentation. All can be done in a org-file beside the source code helping
to make make comments in the source code itself not to verbose.

Nice.... will try it out soon....

As for all the other parts which might be an advantage by using git, you
might be right and it is covered by the tools you mentioned already.

Thanks for your ideas and suggestions.

Greetings,

Totti

[-- Attachment #1.2: Type: text/html, Size: 4498 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Re: org-mode meets git a first proposal ?!
  2009-07-24 13:17   ` Jason F. McBrayer
@ 2009-07-24 15:35     ` Torsten Wagner
  0 siblings, 0 replies; 7+ messages in thread
From: Torsten Wagner @ 2009-07-24 15:35 UTC (permalink / raw)
  To: Jason F. McBrayer; +Cc: emacs-orgmode


[-- Attachment #1.1: Type: text/plain, Size: 765 bytes --]

2009/7/24 Jason F. McBrayer <jmcbray@carcosa.net>

> Matthew Lundin <mdl@imapmail.org> writes:
>
> > That said, I think it would be nice to be able to create links to
> > particular git commits.
>
> Yes, I think that's 80% of the benefit of this idea for 20% of the
> work.   It might be generalizable to, to say when creating a file link
> that if the file is under version control, to have a simple link syntax
> for specifying a revision, and make it simple to specify the revision
> that was active when the link was made.


Dear Jasonm
thanks for focusing my woolly thoughts....
you and Matt are right... first of all I like the idea of having frozen
links
everything else might be a "nice to have" or might be covered by other modes
already

Greetings

Totti

[-- Attachment #1.2: Type: text/html, Size: 1173 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: org-mode meets git a first proposal ?!
  2009-07-24  3:32 org-mode meets git a first proposal ?! Torsten Wagner
  2009-07-24  5:18 ` Matthew Lundin
@ 2009-07-26 20:40 ` Bastien
  2009-08-03  4:39   ` Carsten Dominik
  1 sibling, 1 reply; 7+ messages in thread
From: Bastien @ 2009-07-26 20:40 UTC (permalink / raw)
  To: Torsten Wagner; +Cc: emacs-orgmode

Hi Totti,

just a few words regarding preserving links.

About /finding/ links, I just added this simple function, which is 
quite handy I guess:


(defun org-occur-link-in-agenda-files ()
  "Create a link and search for it in the agendas.
The link is not stored in `org-stored-links', it is just created
for the search purpose."
  (interactive)
  (let ((link (condition-case nil
		  (org-store-link nil)
		(error "Unable to create a link from here"))))
    (org-occur-in-agenda-files (regexp-quote link))))


For example, you are in your mailbox, you have the nasty feeling that
this old mail you are re-reading has been stored in your agenda, this
function helps you find it.

About preserving links -- yes, this is a problem.  I tried to implement
a registry long time ago: this is org-registry.el in the contrib/ dir.
Please have a look.  I don't maintain it anymore, but it might be still
usable.  If people are interested in using it more, I will look at it
again.

Another simple and useful approach: I often break links by moving a file
from dired.  A solution could be to advise dired-do-rename so that it
checks whether the file(s) at point is/are link(s) in an org file.  If
so, the function could just send a warning, and maybe update the links.
That would be a beginning.  Of course, this doesn't fix the problem 
when moving files from the shell...

As for linking to specific versions of a file under versioning, I have 
a few ideas I'm working on, I let you know later.

Thanks!

-- 
 Bastien

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: org-mode meets git a first proposal ?!
  2009-07-26 20:40 ` Bastien
@ 2009-08-03  4:39   ` Carsten Dominik
  0 siblings, 0 replies; 7+ messages in thread
From: Carsten Dominik @ 2009-08-03  4:39 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode


On Jul 26, 2009, at 10:40 PM, Bastien wrote:

> Hi Totti,
>
> just a few words regarding preserving links.
>
> About /finding/ links, I just added this simple function, which is
> quite handy I guess:
>
>
> (defun org-occur-link-in-agenda-files ()
>  "Create a link and search for it in the agendas.
> The link is not stored in `org-stored-links', it is just created
> for the search purpose."
>  (interactive)
>  (let ((link (condition-case nil
> 		  (org-store-link nil)
> 		(error "Unable to create a link from here"))))
>    (org-occur-in-agenda-files (regexp-quote link))))

Nice one! I have added a menu entry for it.

>
>
> For example, you are in your mailbox, you have the nasty feeling that
> this old mail you are re-reading has been stored in your agenda, this
> function helps you find it.
>
> About preserving links -- yes, this is a problem.  I tried to  
> implement
> a registry long time ago: this is org-registry.el in the contrib/ dir.
> Please have a look.  I don't maintain it anymore, but it might be  
> still
> usable.  If people are interested in using it more, I will look at it
> again.
>
> Another simple and useful approach: I often break links by moving a  
> file
> from dired.  A solution could be to advise dired-do-rename so that it
> checks whether the file(s) at point is/are link(s) in an org file.  If
> so, the function could just send a warning, and maybe update the  
> links.
> That would be a beginning.  Of course, this doesn't fix the problem
> when moving files from the shell...

Please also consider using ID links which are made to survive
when files are moved around.  As long as the link definition remains
in one of the agenda files, the links will still work.

- Carsten

>
> As for linking to specific versions of a file under versioning, I have
> a few ideas I'm working on, I let you know later.
>
> Thanks!
>
> -- 
> Bastien
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-08-03  4:39 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-24  3:32 org-mode meets git a first proposal ?! Torsten Wagner
2009-07-24  5:18 ` 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

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).