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.
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).
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.
Well, they never need a PDF other than the latest version, will they?
Then, you don't need Git to send them your PDFs, just upload the PDFs
somewhere where your supervisors can grab them periodically, and
you're done.
The issue is when they start modifying the LaTeX files: then you have
to think of merging, and you'd better do that with a revision control
system.
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.
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.
--
Matthieu
On 08/27/2009 10:55 PM, Matthieu Moy wrote:
seanh[off-list ref] writes:
quoted
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 ?
quoted
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.
quoted
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