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

[Achim Gratz <Stromeko@nexgo.de>]

Bastien <bastien.guerry@wikimedia.fr> writes:
>>  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]]

Just like org-protocol and org-annotate-helper this uses an opaque URI
and positional arguments, something I'm not too fond of.  It's easily
broken and hard to extend in a backwards-compatible manner.  If all uses
of URI-like syntax were stratified to a single general form within
orgmode, it would become a lot easier to move data back and forth using
these URI, IMHO.

Since the function is searching for something after the resource has
been retrieved by the application that requested it, it should probably
have URI fragment syntax, see RFC 2396 (this RFC actually replaces
RFC1738 that org-protocol still references).  Likewise the specification
of what version to retrieve from Git should probably be in query syntax
since it's done by the server of the request.  Last but not least, the
git scheme is already in use by git for specifying remotes, so I'd
suggest not clobbering that namespace from within org.  The use of "@"
is reserved in certain places and use of braces is labeled "unwise".
Hence something like:

 [[org://authority/git:/~/my.org?b=master;d=2011-02-07#Org%20code]]                                 

looks to be more friendly considering that maybe these links diffuse
outside of org and are tried to be interpreted by URI parsers.  It opens
up a way to ask org servers for their data (when the authority segment
is present, if not it uses the local data as implied by the org document
containing the URI) and enables a uniform way to introduce sub-handlers
(git:/ in this case).  Org-protocol does some of that already and should
be able to be extended to include the proposal above.  The arguments are
also named, so they can come in any order.  Just a thought.

[Note: emacsclient does only strip down consecutive slashes for what it
considers the path to files.  It's perfectly OK to give it a lisp
expression that contains a string with as many slashes as you see fit,
like this one.  This might be a better way to get URI arguments to emacs
server, then: emacsclient -e '(org-parse-URI "org:...")']


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds