Re: Using git to track my PhD thesis, couple of questions

seanh [off-list ref] 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. 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`. Btw the help for that command ends quite brilliantly: 
"(or more in case of an octopus)".

2. They don't want to look at the latex source but the PDFs built from 
it, which they're going to annotate with their comments. So I need an 
easy way for them to get the PDF of each commit from gitweb without 
having to checkout the repo and build it themselves. 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?

What I would do if I were you (and I did something similar recently while
working on my book) is something like this:

 * Keep your source in git.  Do not worry about the commit granularity.
   Commit as often as you think makes sense.

 * Have a Makefile to build pdf if you have not done so.

 * Dedicate a separate directory, for review pupose.  Have a separate git
   repository there.  If you choose to use an untracked subdirectory
   'publish' of your source work tree (you do not have to), you would do
   something like this:

	$ mkdir publish
        $ (cd publish && git init)

   Arrange things so that "git push" in that repository will propagate its
   contents to the public repository your advisors will look at.

 * Have a 'publish' target in your Makefile, which would roughly do:

	#!/bin/sh

	make pdf &&
        cp paper.pdf publish/. &&

        this=$(git rev-parse HEAD) &&
        prev=$(cd publish &&
               git show -s | sed -ne 's/^ *Changes up to: \(.*\)$/\1/p'
	) &&
	{
		echo "Changes up to: $this"
                echo
                case "$prev" in
                '') # initial round
                        git shortlog ;;
                ?*)
                        git shortlog $prev.. ;;
                esac
	} >publish/log &&
        cd publish &&
        git add paper.pdf &&
        git commit -F log &&
        git push

 * Then when you want to submit the current status for review (perhaps you
   would want this to happen at the end of each day, or every other day,
   or whatever), type

    $ make publish

The idea is:

 (1) If your source material is not interesting to your advisors at all,
     there is no point showing, let alone the commit granularity of your
     work; and

 (2) If your advisors want to see PDF and PDF only, then give them that,
     but as you correctly said, that is a cruft from your source's point
     of view, so do not mix them together.