{"thread":{"id":"26532","subject":"use case: keep the output of a markup (TeX) file under revision control","startedAt":"2011-02-17T10:37:00Z","lastAt":"2011-02-18T06:59:36Z","messageCount":6,"participants":["Paul Menzel","Stefan Naewe","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161402","messageId":"1297939020.3959.12.camel@mattotaupa","threadId":"26532","inReplyTo":null,"subject":"use case: keep the output of a markup (TeX) file under revision control","fromName":"Paul Menzel","fromEmail":"paulepanter@users.sourceforge.net","sentAt":"2011-02-17T10:37:00Z","receivedAt":"2011-02-17T10:37:00Z","isPatch":false,"sender":{"key":"paulepanter@users.sourceforge.net","avatar":null},"body":"Dear Git folks,\n\n\n(Please CC me when replying since I am not subscribed.)\n\nI have the following use case and need an advise from you professionals.\n\nA friend and I are writing a paper using TeX¹ and keep the files under\nrevision control using Git. This works fine so far. But I want to also\nhave the output (PDF) of the markup file under revision control to be\nable to access the PDF files even if for example no TeX installation is\navailable on a system.\n\nThe problem now is, since the output is no plain text file, that\nmerging/rebasing always shows conflicts which Git, of course, cannot\nsolve.\n\nIs there a way to set that up so that there are no conflicts? Would a\npre-commit hook work which generates the PDF file prior to committing?\nAnd if no TeX installation is available it would just ignore the PDF\nfiles?\n\nI could not find anything on the Web because having PDF as search string\nwould just show up how to generate documentation about Git.\n\n\nThanks,\n\nPaul\n\n\n¹ Actually it is ConTeXt [1].\n\n[1] http://wiki.contextgarden.net/Main_Page\n"},{"id":"161405","messageId":"4D5D0EA2.4000805@atlas-elektronik.com","threadId":"26532","inReplyTo":"1297939020.3959.12.camel@mattotaupa","subject":"Re: use case: keep the output of a markup (TeX) file under revision control","fromName":"Stefan Naewe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2011-02-17T12:03:46Z","receivedAt":"2011-02-17T12:03:46Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"On 2/17/2011 11:37 AM, Paul Menzel wrote:\n> Dear Git folks,\n> \n> \n> (Please CC me when replying since I am not subscribed.)\n> \n> I have the following use case and need an advise from you professionals.\n> \n> A friend and I are writing a paper using TeX¹ and keep the files under\n> revision control using Git. This works fine so far. But I want to also\n> have the output (PDF) of the markup file under revision control to be\n> able to access the PDF files even if for example no TeX installation is\n> available on a system.\n> \n> The problem now is, since the output is no plain text file, that\n> merging/rebasing always shows conflicts which Git, of course, cannot\n> solve.\n> \n> Is there a way to set that up so that there are no conflicts? Would a\n> pre-commit hook work which generates the PDF file prior to committing?\n> And if no TeX installation is available it would just ignore the PDF\n> files?\n> \n> I could not find anything on the Web because having PDF as search string\n> would just show up how to generate documentation about Git.\n\nWhy don't you keep the PDF files in a separate branch ? Look at git's\ngit repository (http://git.kernel.org/?p=git/git.git) in the html \nand man branches.\n\nRegards,\n Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: If at first you don't succeed, work for Microsoft.\n"},{"id":"161410","messageId":"m362si97n4.fsf@localhost.localdomain","threadId":"26532","inReplyTo":"1297939020.3959.12.camel@mattotaupa","subject":"Re: use case: keep the output of a markup (TeX) file under revision control","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-17T12:19:12Z","receivedAt":"2011-02-17T12:19:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Paul Menzel writes:\n\n> I have the following use case and need an advise from you professionals.\n> \n> A friend and I are writing a paper using TeX¹ and keep the files under\n> revision control using Git. This works fine so far. But I want to also\n> have the output (PDF) of the markup file under revision control to be\n> able to access the PDF files even if for example no TeX installation is\n> available on a system.\n> \n> The problem now is, since the output is no plain text file, that\n> merging/rebasing always shows conflicts which Git, of course, cannot\n> solve.\n> \n> Is there a way to set that up so that there are no conflicts? Would a\n> pre-commit hook work which generates the PDF file prior to committing?\n> And if no TeX installation is available it would just ignore the PDF\n> files?\n> \n> I could not find anything on the Web because having PDF as search string\n> would just show up how to generate documentation about Git.\n\nAs an alternative to Stefan Naewe solution of using separate \"orphan\"\n(unrelated) branch to store PDF files, like Git project does with\ngenerated documentation (manpages in 'man' branch, HTML version in\n'html' branch), you can try the following:\n\n1. Mark PDF files as binary, if they are not already considered binary.\n\n2. Create custom merge driver for PDF files, which would compile\n source *.tex file to PDF, provided that TeX is installed, and that\n source file itself is not in merge conflict\n\n3. Creating pre-commit hook would ensure that you have refershed PDF\n files during ordinary commit. Note that this hook is not always ran\n (you can force running it with --verify option to git-commit).\n\nHTH\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"161412","messageId":"4D5D1415.7080405@atlas-elektronik.com","threadId":"26532","inReplyTo":"m362si97n4.fsf@localhost.localdomain","subject":"Re: use case: keep the output of a markup (TeX) file under revision control","fromName":"Stefan Naewe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2011-02-17T12:27:01Z","receivedAt":"2011-02-17T12:27:01Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"On 2/17/2011 1:19 PM, Jakub Narebski wrote:\n> Paul Menzel writes:\n> \n> 1. Mark PDF files as binary, if they are not already considered binary.\n> \n> 2. Create custom merge driver for PDF files, which would compile\n> source *.tex file to PDF, provided that TeX is installed, and that\n> source file itself is not in merge conflict\n> \n> 3. Creating pre-commit hook would ensure that you have refershed PDF\n> files during ordinary commit. Note that this hook is not always ran\n> (you can force running it with --verify option to git-commit).\n\n??\n\nI only see '--no-verify' in 'git help commit' to bybass the \n'pre-commit' hook but not the other way round.\n\nPuzzled,\n Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: Beam me up Scotty. This isn't the men's room.\n"},{"id":"161442","messageId":"1297972319.3944.30.camel@mattotaupa","threadId":"26532","inReplyTo":"4D5D0EA2.4000805@atlas-elektronik.com","subject":"Re: use case: keep the output of a markup (TeX) file under revision control","fromName":"Paul Menzel","fromEmail":"paulepanter@users.sourceforge.net","sentAt":"2011-02-17T19:51:59Z","receivedAt":"2011-02-17T19:51:59Z","isPatch":false,"sender":{"key":"paulepanter@users.sourceforge.net","avatar":null},"body":"Am Donnerstag, den 17.02.2011, 13:03 +0100 schrieb Stefan Naewe:\n> On 2/17/2011 11:37 AM, Paul Menzel wrote:\n\n> > (Please CC me when replying since I am not subscribed.)\n> > \n> > I have the following use case and need an advise from you professionals.\n> > \n> > A friend and I are writing a paper using TeX¹ and keep the files under\n> > revision control using Git. This works fine so far. But I want to also\n> > have the output (PDF) of the markup file under revision control to be\n> > able to access the PDF files even if for example no TeX installation is\n> > available on a system.\n> > \n> > The problem now is, since the output is no plain text file, that\n> > merging/rebasing always shows conflicts which Git, of course, cannot\n> > solve.\n> > \n> > Is there a way to set that up so that there are no conflicts? Would a\n> > pre-commit hook work which generates the PDF file prior to committing?\n> > And if no TeX installation is available it would just ignore the PDF\n> > files?\n> > \n> > I could not find anything on the Web because having PDF as search string\n> > would just show up how to generate documentation about Git.\n> \n> Why don't you keep the PDF files in a separate branch ? Look at git's\n> git repository (http://git.kernel.org/?p=git/git.git) in the html \n> and man branches.\n\nVery interesting. Thank you very much for this hint.\n\nIs the used solution in git’s git repository a result of the problem\nwith maintaining generated output from source files or does it have\nother other advantages too?\n\nWhen creating TeX documents – at least in my work flow – I always have\nthe PDF file open in parallel. Would that be a problem when having it in\na separate branch?\n\nAlso I guess that this is done automatically too (saying autogenerated\nin `git log origin/man`). I could not find the script though.\n\n $ git grep Autogen\n git-gui/Makefile: echo '# Autogenerated by git-gui Makefile' >$@ && \\\n git-gui/git-gui.sh:if {[gets $fd] eq {# Autogenerated by git-gui Makefile}} {\n\nand searching for »git \"Autogenerated manpages for\"« did not return\nanything useful for me.\n\nAdditionally I am confused where the SHA id g43f9f in »Autogenerated\nmanpages for v1.7.4.1-42-g43f9f« comes from. I could not find that\ncommit in `origin/master` or `git log v1.7.4.1`.\n\nThe last thing is that in git’s git repository the autogeneration of the\nmanual pages does not seem to happen every commit (Is it a cron job?).\nIn my use case the PDF file should be generated after every commit. Is a\nseparate branch the way to go here?\n\n\nThanks,\n\nPaul\n"},{"id":"161514","messageId":"4D5E18D8.8030106@atlas-elektronik.com","threadId":"26532","inReplyTo":"1297972319.3944.30.camel@mattotaupa","subject":"Re: use case: keep the output of a markup (TeX) file under revision control","fromName":"Stefan Naewe","fromEmail":"stefan.naewe@atlas-elektronik.com","sentAt":"2011-02-18T06:59:36Z","receivedAt":"2011-02-18T06:59:36Z","isPatch":false,"sender":{"key":"stefan.naewe@gmail.com","avatar":"https://avatars.githubusercontent.com/u/4468?v=4"},"body":"On 2/17/2011 8:51 PM, Paul Menzel wrote:\n>> Why don't you keep the PDF files in a separate branch ? Look at git's\n>> git repository (http://git.kernel.org/?p=git/git.git) in the html \n>> and man branches.\n> \n> Very interesting. Thank you very much for this hint.\n> \n> Is the used solution in git’s git repository a result of the problem\n> with maintaining generated output from source files or does it have\n> other other advantages too?\n> \n> When creating TeX documents – at least in my work flow – I always have\n> the PDF file open in parallel. Would that be a problem when having it in\n> a separate branch?\n\nI'd create a second clone and checkout the 'PDF' (or whatever you might call\nit) branch there.\n\n> Also I guess that this is done automatically too (saying autogenerated\n> in `git log origin/man`). I could not find the script though.\n> \n> $ git grep Autogen\n> git-gui/Makefile: echo '# Autogenerated by git-gui Makefile' >$@ && \\\n> git-gui/git-gui.sh:if {[gets $fd] eq {# Autogenerated by git-gui Makefile}} {\n> \n> and searching for »git \"Autogenerated manpages for\"« did not return\n> anything useful for me.\n\nTry: git grep \"Autogenerated \" origin/todo\nIt's in 'dodoc.sh' on branch 'todo'\n\n> Additionally I am confused where the SHA id g43f9f in »Autogenerated\n> manpages for v1.7.4.1-42-g43f9f« comes from. I could not find that\n> commit in `origin/master` or `git log v1.7.4.1`.\n\nTry: git show 43f9f (and 'git help describe')\n \n> The last thing is that in git’s git repository the autogeneration of the\n> manual pages does not seem to happen every commit (Is it a cron job?).\n> In my use case the PDF file should be generated after every commit. Is a\n> separate branch the way to go here?\n\nI guess the autogeneration takes place on every push to 'master'. That\nshould work for you, too. Your decision...\n\nHTH,\n Stefan\n-- \n----------------------------------------------------------------\n/dev/random says: I was going to procrastinate, but I put it off....\n"}]}