use case: keep the output of a markup (TeX) file under revision control

> Dear Git folks,
> 
> 
> (Please CC me when replying since I am not subscribed.)
> 
> I have the following use case and need an advise from you professionals.
> 
> A friend and I are writing a paper using TeX¹ and keep the files under
> revision control using Git. This works fine so far. But I want to also
> have the output (PDF) of the markup file under revision control to be
> able to access the PDF files even if for example no TeX installation is
> available on a system.
> 
> The problem now is, since the output is no plain text file, that
> merging/rebasing always shows conflicts which Git, of course, cannot
> solve.
> 
> Is there a way to set that up so that there are no conflicts? Would a
> pre-commit hook work which generates the PDF file prior to committing?
> And if no TeX installation is available it would just ignore the PDF
> files?
> 
> I could not find anything on the Web because having PDF as search string
> would just show up how to generate documentation about Git.

> > (Please CC me when replying since I am not subscribed.)
> > 
> > I have the following use case and need an advise from you professionals.
> > 
> > A friend and I are writing a paper using TeX¹ and keep the files under
> > revision control using Git. This works fine so far. But I want to also
> > have the output (PDF) of the markup file under revision control to be
> > able to access the PDF files even if for example no TeX installation is
> > available on a system.
> > 
> > The problem now is, since the output is no plain text file, that
> > merging/rebasing always shows conflicts which Git, of course, cannot
> > solve.
> > 
> > Is there a way to set that up so that there are no conflicts? Would a
> > pre-commit hook work which generates the PDF file prior to committing?
> > And if no TeX installation is available it would just ignore the PDF
> > files?
> > 
> > I could not find anything on the Web because having PDF as search string
> > would just show up how to generate documentation about Git.
> 
> Why don't you keep the PDF files in a separate branch ? Look at git's
> git repository (http://git.kernel.org/?p=git/git.git) in the html 
> and man branches.

>> Why don't you keep the PDF files in a separate branch ? Look at git's
>> git repository (http://git.kernel.org/?p=git/git.git) in the html 
>> and man branches.
> 
> Very interesting. Thank you very much for this hint.
> 
> Is the used solution in git’s git repository a result of the problem
> with maintaining generated output from source files or does it have
> other other advantages too?
> 
> When creating TeX documents – at least in my work flow – I always have
> the PDF file open in parallel. Would that be a problem when having it in
> a separate branch?

> Also I guess that this is done automatically too (saying autogenerated
> in `git log origin/man`). I could not find the script though.
> 
>         $ git grep Autogen
>         git-gui/Makefile:        echo '# Autogenerated by git-gui Makefile' >$@ && \
>         git-gui/git-gui.sh:if {[gets $fd] eq {# Autogenerated by git-gui Makefile}} {
> 
> and searching for »git "Autogenerated manpages for"« did not return
> anything useful for me.

> I have the following use case and need an advise from you professionals.
> 
> A friend and I are writing a paper using TeX¹ and keep the files under
> revision control using Git. This works fine so far. But I want to also
> have the output (PDF) of the markup file under revision control to be
> able to access the PDF files even if for example no TeX installation is
> available on a system.
> 
> The problem now is, since the output is no plain text file, that
> merging/rebasing always shows conflicts which Git, of course, cannot
> solve.
> 
> Is there a way to set that up so that there are no conflicts? Would a
> pre-commit hook work which generates the PDF file prior to committing?
> And if no TeX installation is available it would just ignore the PDF
> files?
> 
> I could not find anything on the Web because having PDF as search string
> would just show up how to generate documentation about Git.

> Paul Menzel <paulepanter@users.sourceforge.net> writes:
> 
> 1. Mark PDF files as binary, if they are not already considered binary.
> 
> 2. Create custom merge driver for PDF files, which would compile
>    source *.tex file to PDF, provided that TeX is installed, and that
>    source file itself is not in merge conflict
> 
> 3. Creating pre-commit hook would ensure that you have refershed PDF
>    files during ordinary commit.  Note that this hook is not always ran
>    (you can force running it with --verify option to git-commit).