From: Paul Menzel <paulepanter@users.sourceforge.net>
To: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: use case: keep the output of a markup (TeX) file under revision control
Date: Thu, 17 Feb 2011 20:51:59 +0100 [thread overview]
Message-ID: <1297972319.3944.30.camel@mattotaupa> (raw)
In-Reply-To: <4D5D0EA2.4000805@atlas-elektronik.com>
[-- Attachment #1: Type: text/plain, Size: 2631 bytes --]
Am Donnerstag, den 17.02.2011, 13:03 +0100 schrieb Stefan Naewe:
> On 2/17/2011 11:37 AM, Paul Menzel wrote:
> > (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.
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.
Additionally I am confused where the SHA id g43f9f in »Autogenerated
manpages for v1.7.4.1-42-g43f9f« comes from. I could not find that
commit in `origin/master` or `git log v1.7.4.1`.
The last thing is that in git’s git repository the autogeneration of the
manual pages does not seem to happen every commit (Is it a cron job?).
In my use case the PDF file should be generated after every commit. Is a
separate branch the way to go here?
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2011-02-17 19:52 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 [this message]
2011-02-18 6:59 ` Stefan Naewe
2011-02-17 12:19 ` Jakub Narebski
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=1297972319.3944.30.camel@mattotaupa \
--to=paulepanter@users.sourceforge.net \
--cc=git@vger.kernel.org \
--cc=stefan.naewe@atlas-elektronik.com \
/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