Wow, really helpful responses, thanks a lot. I think having read all this that I'll do it manually. I'll still use git to track my latex source and will commit to it as often as I like and not worry about commit granularity. Whenever I've finished a significant chunk I'll add a PDF of it to a manually edited web page along with a description of what changed since the last time I added a PDF. I can use git log etc to help write the manual changelog. My supervisors can just look at this manually constructed page and if it gets too big I'll just archive the oldest PDFs. I can tag the git repo at the points where I add a PDF to the web page. I guess this is pretty close to what software projects do with version releases and their public website. On Thu, Aug 27, 2009 at 01:41:04PM -0700, Sverre Rabbelier wrote: > If they only care about the pdf anyway, why not have a separate branch > to which you commit the pdf's instead? Well I was thinking they'd look at the changelogs with the diffs showing exactly what changed in the latex source files, which should be pretty self-explanatory, but then when they wanted to read a whole chapter and add comments to it they'd want the PDF not the latex. I don't really understand the script Junio posted (not literate in sh) but I think it might have something to do with copying changelogs over from the source repo to a PDFs repo. On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote: > As you can generate the PDF's from the latex then just hack gitweb to > let them download it from there. Unfortunately gitweb is written in Perl. But I know what you mean, it should in theory be possible for them to click on a 'Get PDF' link for a particular revision that causes the PDF to be built and returned to their browser. In response to Matthieu and Paolo, I'm not sure I understand the git internals involved in the discussion around merge --squash, I had a feeling this would produce a 'merge' that git in some sense would 'not know about', since it sounds complex and I don't understand it I don't think I want to go there. Thanks all -- 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