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). > 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 -- 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