From: Paolo Bonzini <bonzini@gnu.org>
Date: Fri, 28 Aug 2009 08:34:24 GMT
Subject: Re: Using git to track my PhD thesis, couple of questions
Message-ID: <4A979690.1050601@gnu.org>
In-Reply-To: <vpqk50pasek.fsf@bauges.imag.fr>

On 08/27/2009 10:55 PM, Matthieu Moy wrote:
> seanh<seanh.nospam@gmail.com>  writes:
>
>> I'm planning to use git to track my PhD thesis as I work on it and to
>> let my supervisors track it. I've setup a git repository and a gitweb
>> instance showing it. There are a couple of specific requirements.
>>
>> 1. My supervisors don't want to see all the little commits that I make
>> day by day.
>
> I'm not sure I understand why you want that. From what you say, your
> supervisors won't be looking at the LaTeX source, so they won't read
> the diffs for the commits. Instead, they will be looking at regular
> snapshots in PDF. So, how is that disturbing to keep the intermediate
> commits ?
>
>> So I'll commit to a dev branch, then whenever I've made
>> significant progress will merge it into a trunk branch. I want the trunk
>> branch to get all the changes but as one big commit, not inherit all the
>> little commits like a normal merge would do. I think this is a `git
>> merge --squash`.
>
> It is, but this also means _you_ will somehow lose your intermediate
> commits. Well, you may not really lose them, but after a merge
> --squash, you have two options to continue working: work on top of the
> squashed commit (and then your ancestry doesn't contain the small
> ones), or work on top of your previous branches (and then, you don't
> have a proper merge tracking, and you'll get spurious conflicts if you
> try another merge --squash).

You can also merge from the master to your working branch after every 
merge --squash.

    ... work on local ...
    git commit
    ... work on local ...
    git commit

    git checkout master
    git merge --squash local; git commit -m'day 1'
    git checkout local
    git merge master

> I also used a revision control system to write my Ph.D (Git was born
> after I started writting, so it wasn't Git yet), and my reviewing
> system has been all the more simple: when a chapter is done, send an
> email with the PDF attached, and "Hi, chapter $n is done, can you have
> a look?". That just works.

That's the same I did.  I used git, but only locally.  I never published 
the repository for my supervisor, she didn't care.

>> Normally I wouldn't commit the PDF files into the repo because
>> they're compiled files not source files, but it seems that just
>> building a PDF and committing it along with each commit to trunk
>> would be by far the easiest way to achieve this. But will git store
>> the PDFs efficiently, or will the repo start to get really big?
>
> Git will do delta-compression as it can, but I don't think PDFs will
> delta-compress very well, so your repository may grow rather quickly,
> yes. If possible, commit the PDFs on a separate branch so that you can
> easily keep your clean history small in disk space, and discard the
> PDFs if needed.

That's a good advice.  Remember to delete the branch reflog too if you 
want to clean the history.

You can also try \pdfcompresslevel=0, which would probably make 
delta-compression behave better at the expense of distributing bigger 
files to your supervisor.  If you use hyperref, see this:

    http://www.tug.org/pipermail/pdftex/2003-August/004402.html

Best of all would be to have filters doing/undoing the PDF compression, 
but I know of no free program doing this.

Paolo