Re: [Orgmode] org-git-link does not support locational information within file

[Gregor Kappler]

Hi Bastien,

Thanks for your answer. I was surprised and glad to hear so much interest in 
my particular problem.

On Fri, 11 Feb 2011 18:17:58 +0100, Bastien <address@hidden> wrote:
> >  2. use git versioned files transparently, i.e. org-git-store-link
> >     should support search (org-ids and text files) in linked git
> >     revisions of files.
> 
> I've look into this.  We could code things to add a search string:
> 
>   [[git:~/my.org::address@hidden::Org code]]
>                                      ^^
> 
> ... but I'm reluctant to change the general syntax of links, even 
> if that's just for git links.

It might be better to stick to org-mode's convention of storing the "location 
within the file" after "::", a convention your current syntax is not adhering 
to.
I think you could stay consistent with the current general syntax of orgmode by 
switching from

[[git:~/my.org::address@hidden::Org code]]

to

[[git:~/address@hidden::Org code]]
or 
[[git:~/my.org?master{2011-02-11}::Org code]]

This would fully break existing links.
Achim Gratz contributed some good points about changing the git-link syntax and 
made a more founded proposal for a changed syntax though. Achim seems to focus 
strongly on machine readability. For me, I like to be able to read links easily.


[[git:<repository or file>?<revision information>::<location in file>]]
<revision information> can be
- a date+time value (for me, time is important here)
- a SHA
- "HEAD"

> 
> >  3. define an interactive function that can update the revision
> >     information of a link at mark to the current branch head of the
> >     file (so I can update all links to new FS folder structure.)
> 
> You mean update
> 
>   [[git:~/my.org::address@hidden::Org code]]
> 
> to 
> 
>   [[git:~/my.org::address@hidden::Org code]]
> 
> ?
> 
> Can you provide an explicit example?

Let the function be of name org-git-link-update-to-head.
I will adhere to the syntax in your post. 
I guess all scenarios can be made explicit by two conditions:

1. The file is still of the same name. Calling org-git-link-update-to-head on 

   [[git:~/my.org::address@hidden::Org code]]

   would change the link to

   [[git:~/my.org::address@hidden::Org code]]

   (today being the 15th)

2. more interesting is the case that the file was moved by e.g by

   git mv my.org your.org

   Then optimally git would be queried for the actual location of a newer 
version in HEAD (if unique). 
   (I am actually not sure how to do this with git, but should be viable)

   The link should be rewritten by org-git-link-update-to-head to
   [[git:~/your.org::address@hidden::Org code]]


   This file might have been edited meanwhile by e.g. 

   echo "* annoying tail heading" >> your.org && git add your.org && git commit 
-m ""

   Still the new link should become
   [[git:~/your.org::address@hidden::Org code]]

If HEAD would be added to the possible revision definition, 
org-git-link-update-to-head cannot identify the file after moving. On the other 
hand, having this function one would not want to point to head.

Another possibility would be not to rewrite links but to resolve the
current revision as outlined on the fly in org-open-at-point.

> > I am still lame at elisp - so my implementation skills are
> > limited. With the great work in org-git-link all backend stuff seems
> > there, only needing more glue. Any hints how to achieve this would be
> > very welcome!
> 
> org-git-link.el is quite readable, and I'd welcome ideas on how to
> extend it to fulfill your wishes without extending Org's link syntax 
> too much...

I try to learn elisp bit by bit. Found a good tutorial finally.
I got busy times around me - need to constrain fiddle-time.


Cheers and thanks,

Gregor

-- 
--

Dr. Gregor Kappler

Fakultät für Psychologie 
Institut für Entwicklungspsychologie und 
Psychologische Diagnostik
http://www.univie.ac.at/Psychologie

Universität Wien
Liebiggasse 5
A-1010 Wien
mail: address@hidden
tel: +43 1 4277 47866