On 08/27/2009 10:55 PM, Matthieu Moy wrote:
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.
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
--
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