From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: Best practices for literate programming [was: Latex export of tables]
Date: Thu, 18 Apr 2013 21:48:46 +0200 [thread overview]
Message-ID: <87vc7jhb6p.fsf@Rainer.invalid> (raw)
In-Reply-To: 87r4i7ra7z.fsf@gmail.com
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
next prev parent reply other threads:[~2013-04-18 19:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 8:06 Latex export of tables Vikas Rawal
2013-04-14 23:29 ` Suvayu Ali
2013-04-16 11:56 ` Vikas Rawal
2013-04-16 13:13 ` Thomas Alexander Gerds
2013-04-16 17:39 ` Suvayu Ali
2013-04-16 20:07 ` Thomas S. Dye
2013-04-16 21:39 ` Suvayu Ali
2013-04-16 23:45 ` Thomas S. Dye
2013-04-17 10:21 ` Myles English
2013-04-16 22:10 ` Best practices for literate programming [was: Latex export of tables] Vikas Rawal
2013-04-17 0:06 ` Thomas S. Dye
2013-04-18 16:53 ` Rasmus
2013-04-18 17:59 ` Aaron Ecay
2013-04-18 18:25 ` Rasmus
2013-04-18 19:48 ` Achim Gratz [this message]
2013-04-18 19:42 ` Thomas S. Dye
2013-04-21 17:25 ` Rasmus Pank Roulund
2013-04-17 6:39 ` Suvayu Ali
2013-04-17 9:55 ` Rainer M. Krug
2013-04-17 10:10 ` Suvayu Ali
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=87vc7jhb6p.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--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).