emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Best practices for literate programming [was: Latex export of ta


From: Achim Gratz
Subject: Re: [O] Best practices for literate programming [was: Latex export of tables]
Date: Thu, 18 Apr 2013 21:48:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Aaron Ecay writes:
> If your external org configuration file were kept under version control
> (I’ll discuss git but the principle is general), then reproducibility
> would be possible.

There's a lot more to reproducibility then just this, but yes, the
configuration files would have to be part of it.

> There are ways of embedding git hashes in LaTeX
> documents (for one example:
> http://thorehusfeldt.net/2011/05/13/including-git-revision-identifiers-in-latex/),
> and of course org could help automate this.  Including the git hash of
> the document itself, the config file, and org-mode’s own code (assuming
> these are kept in 3 separate repos) should allow perfect reproducibility
> (modulo incompatible changes in emacs, I guess).

This is confused thinking and doesn't help anyway with the problem at
hand.  The purpose of Git is to record (and later re-create) the
complete state of your work tree, so monkeying around with hashes
embedded in document sources isn't making progress and recording several
hashes is either superfluous or a sign of incomplete control over the
work tree (you'd maybe want to use submodules).

What you can and should do however is putting a Git hash into the final
document so that this can be linked back to some state of the worktree
(like Org does for its manual and installed sources).

> It would be interesting for org to have an ability to reference files
> not just by name, but by git revision.  So that you could do something
> like (where 123456 is some git hash):
> #+include: [[gitbare:/path/to/repo::123456:my-org-setup-file.org]]
> and have org take care of checking out the proper revision and loading
> the file in the usual way.  This syntax is already implemented, for
> plain links, in contrib/lisp/org-git-link.el, so it is just a matter
> of making #+include and friends understand links in addition to
> filenames.

Git revisions are for the whole tree (or more precisely the commit that
references the tree), not single files.  If you access a file blob by
it's SHA-1 rather than name, then Git lets you do that, but you bypass
most of Git that way (much like you'd bypass the file system if you
started to access files by block numbers).


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada




reply via email to

[Prev in Thread] Current Thread [Next in Thread]