emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Gregor Kappler <gregor.kappler@univie.ac.at>
To: Bastien <bastien.guerry@wikimedia.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-git-link does not support locational information within file
Date: Tue, 15 Feb 2011 21:11:19 +0100	[thread overview]
Message-ID: <87aahx9hy0.fsf@univie.ac.at> (raw)
In-Reply-To: <87zkq2trqx.fsf@gnu.org>

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 <bastien.guerry@wikimedia.fr> 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::master@{2011-02-07}::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::master@{2011-02-11}::Org code]]

to

[[git:~/my.org@master{2011-02-11}::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::master@{2011-02-07}::Org code]]
> 
> to 
> 
>   [[git:~/my.org::master@{2011-02-11}::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::master@{2011-02-11}::Org code]]

   would change the link to

   [[git:~/my.org::master@{2011-02-15}::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::master@{2011-02-15}::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::master@{2011-02-14}::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: gregor.kappler@univie.ac.at
tel: +43 1 4277 47866

  parent reply	other threads:[~2011-02-15 20:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-03 15:04 org-git-link does not support locational information within file Gregor Kappler
2011-02-11 17:17 ` Bastien
2011-02-11 17:58   ` Samuel Wales
2011-02-11 18:05     ` Samuel Wales
2011-02-12 11:17     ` Bastien
2011-02-12 20:44       ` Samuel Wales
2011-02-13 12:20   ` Achim Gratz
2011-02-15 20:11   ` Gregor Kappler [this message]
2011-02-13  8:14 ` Leo Alekseyev
2011-02-15 20:15   ` Gregor Kappler

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=87aahx9hy0.fsf@univie.ac.at \
    --to=gregor.kappler@univie.ac.at \
    --cc=bastien.guerry@wikimedia.fr \
    --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).