Re: Org + git branches for derived files

[Tim Cross]

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.