git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Paul Menzel <paulepanter@users.sourceforge.net>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>
Subject: Re: use case: keep the output of a markup (TeX) file under revision control
Date: Thu, 17 Feb 2011 04:19:12 -0800 (PST)	[thread overview]
Message-ID: <m362si97n4.fsf@localhost.localdomain> (raw)
In-Reply-To: <1297939020.3959.12.camel@mattotaupa>

Paul Menzel <paulepanter@users.sourceforge.net> writes:

> 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.

As an alternative to Stefan Naewe solution of using separate "orphan"
(unrelated) branch to store PDF files, like Git project does with
generated documentation (manpages in 'man' branch, HTML version in
'html' branch), you can try the following:

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).

HTH
-- 
Jakub Narebski
Poland
ShadeHawk on #git

  parent reply	other threads:[~2011-02-17 12:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17 10:37 use case: keep the output of a markup (TeX) file under revision control Paul Menzel
2011-02-17 12:03 ` Stefan Naewe
2011-02-17 19:51   ` Paul Menzel
2011-02-18  6:59     ` Stefan Naewe
2011-02-17 12:19 ` Jakub Narebski [this message]
2011-02-17 12:27   ` Stefan Naewe

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m362si97n4.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=paulepanter@users.sourceforge.net \
    /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.
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 NNTP newsgroup(s).