Book Revisions with LaTeX and Git
July 5, 2010 § 10 Comments
As anticipated, a quiet summer around these parts as I revise my manuscript on the theory and mechanisms of midcentury fiction. A quick technical update and a couple of questions for those with experience using Git source control for writing projects.
I spent a chunk of the day today getting my head around Git. I’d been thinking about using it for a while and was helped along by my decision to dump Word in favor of LaTeX a couple of months ago; Word’s binary blobs aren’t well suited to version control (though that’s the least of Word’s problems, really). I also use Dropbox, which does basic automatic versioning, so I hadn’t had much reason to mess with the complexity of Git until now. But Dropbox (reasonably enough) only keeps a finite number of old versions of a file, and it doesn’t let you flag any of them to let your future self know what changed in any given rev. And there are a lot of revs, since it creates a new one every time you save a file (there’s no notion of a commit). This is all totally reasonable for Dropbox, which is a dead simple tool that’s made my working life better in every way. But I wanted more control as I hack away at my very long, slightly disorganized, heavily commented, totally in flux mid-revision book.
So … Git. What’s both cool and terrifying about Git is that it morphs the live files in your working directory as you switch from one branch or revision to another. See this concise explanation of the process from Ben Lynn. (Note to self: Do not switch branches while a file is open in your editor.) Git’s worth a look if you haven’t dealt with modern revision control systems before; much easier and niftier than my brief encounters with CVS years ago had lead me to believe.
Anyway, two questions for those more experienced with this stuff than I:
- I’m planning to use branches for the major edits to each chapter, so that I can easily go back and consult or restore the large sections that are inevitably hacked off along the way. Does this make sense? Are tags or clones more appropriate? Are branches overkill? Should I just trust my commented commits on a single trunk? What does your workflow for writing and revising with Git look like?
- Is there any reason not to combine Git and Dropbox? I’ve put my .git directory inside my current project directory, which already lives in my Dropbox folder. I can’t see any harm in this beyond a bit of redundancy, but I’d welcome any warnings from hard-won experience.
Two last things:
One, I’ll put the full manuscript on GitHub or similar once it’s no longer filled with embarrassing and/or libelous comments.
Two, tomorrow’s project is to merge the massive changes between the existing chapter on William Gaddis and the much more compact version that’s been accepted by Contemporary Literature. This is a good problem to have, but trying to manage it is the proximate cause of all this version control business.