seanh <seanh.nospam@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html