From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Org + git branches for derived files
Date: Sat, 14 Aug 2021 09:10:26 +1000 [thread overview]
Message-ID: <87r1ew28a6.fsf@gmail.com> (raw)
In-Reply-To: <87czqh5gt1.fsf@gmail.com>
Ken Mankoff <mankoff@gmail.com> writes:
> Hello,
>
> I think this might be more of a git question than an Org question, but I imagine
> I might find the answer here and that it might be useful to others, so I ask
> here.
>
> I'd like to keep derivative products (the LaTeX output, the final PDF, etc.)
> available in Git, but not commit those changes each time I change the Org file.
> Perhaps git-annex as appropriate for this, but seems over-kill.
>
> Is there some way to mostly-seamlessly commit the LaTeX and/or PDF and/or other
> files to their own git branches but in a way that overwrites the history of that
> branch, so that a small Org file that generates a big binary PDF does not
> pollute the git tree?
>
> Thanks,
>
> -k.
I think your definitely in salmon mode here :-) and swimming against the
flow. Typically, you would not add derived artefacts to git at all. You
have a full history of your original org file versions and therefore can
extract any version and use it to re-generate any version of a derived
artefact, so you would typically just ignore them and just re-generate
as needed.
Of course the 'easy' solution is simply not to do 'git add' on the
artefact until you want it committed. Provided you don't use 'git commit
-a' and only use 'git add' then the modified file will not be added to
git. When your ready to add the updates to git, then do 'git add' and
then commit.
If you really want this, I can think of 2 possible solutions.
The first would be to use git submodules - basically, turn a directory
in your main git repository into a separate git repository that is a
child of your main git repository. When you have generated a new
artefact and want to keep it in git, copy it to the sub-module
repository and commit it there. In your main repository, you would add
the files to .gitignore. Now, unless you copy a new version into the
sub-module directory, it won't be added. It also won't show up in
diffs/patches generated from your main parent repository.
The second solution would be to use the command
git update-index --assume-unchanged FILE_NAME
to prevent git from committing that file and when your ready to commit
it, do
git update-index --no-assume-unchanged FILE_NAME
which will make the file show up in git status etc again.
There is no way I know of to stop git from tracking/recording the
changes - this is how it works and of course, it doesn't work well with
binary or semi-binary files. You will get large diffs when dealing with
PDFs etc.
Personally, if I had to do something like this, I would go with the
sub-module approach rather than 'update-index'. This would at least keep
the 'mess' in a separate git repo so that you can do diffs and patches
on your main repo without lots of 'noise' and it would be less prone to
forgetting to change the file index settings etc.
In the past, when I have had a repository where I wanted a PDF to be
available to users of the repository, rather than adding that PDF to the
repository, I added a command (script, makefile entry etc) that would
generate the derived artefact on demand rather than having it in the
repository.
next prev parent reply other threads:[~2021-08-14 0:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 18:40 Org + git branches for derived files Ken Mankoff
2021-08-13 20:53 ` Juan Manuel Macías
2021-08-13 23:10 ` Tim Cross [this message]
2021-08-14 0:53 ` Mark Barton
2021-08-14 1:53 ` Rob Sargent
2021-08-14 3:44 ` Rob Sargent
2021-08-14 4:21 ` Samuel Wales
2021-08-16 1:02 ` Ken Mankoff
2021-08-16 4:58 ` Rob Sargent
2021-08-31 12:21 ` Timothy
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=87r1ew28a6.fsf@gmail.com \
--to=theophilusx@gmail.com \
--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).