Nitty Gritty: Editing an Edition with Version Control

As an undergraduate, I did a lot of work that got lost. While my mentor’s editing style is commendable, we never really transitioned to a stable method of digitally backing up our files to ensure work never had to be done twice. Our workflow generally consisted of our team proofing pdf copies of transcriptions or dirty OCR and highlighting and commenting—essentially marking up—the differences in the transcription from the source text. Much of this work was done by moving files around in DropBox, but without fail there was always confusion as to what was the most recent copy of the file with the second scanner’s marks and comments. In order to make comments, a version of the document had to be downloaded and edited locally, then uploaded later. This increased the chances of accidentally deleting the wrong version or combining contradictory versions by a lot, and you can imagine my frustration—at the time I was project manager on the anthology my professor was editing—as I consecutively checked Percy Bysshe Shelley’s The Cenci, not once, not twice, but three total times, and even now I am not sure where the definitive checked version is located. I knew there had to be a better way to manage this workflow, and I became obsessed with finding software that could automate this process. In this section I will primarily be discussing a proprietary cloud storage and distributed version control software called GitHub and Git respectively and how I used them to keep track of all my files throughout my editing process.

Git is to GitHub as a wandering Wordsworth is to a cloud: two deliberate and methodical memory banks capable of housing and tracking every alteration and transmission error for a work committed therein. Every computer has a point of access where the user assumes the role of administrator and the nuanced capabilities of the computer can be controlled. Often referred to as the terminal, users can manage all of their files and digital content right at the command line, and, with a distributed version control software downloaded, those files can be monitored by your computer and their versions tracked. Better yet, Git Bash—the command line access terminal with Git’s version control software enabled—communicates directly with GitHub, making backing up files in the cloud as simple as memorizing a few simple commands. So, what you have when you manage your files in this way is a web of interaction wherein all of the files—or witnesses, if you are feeling particularly textual—communicate with each other and update almost automatically to the most recent version while the outdated versions are stored for reference later in the commit history accessible from either GitHub or the command line. Now when I first heard about this I immediately thought of McGann’s complicated webs of sociological interactions between texts, editors, type setters, friends, lovers, and the authors themselves and I couldn’t help but think that this work may lend itself to this type of software perhaps even more so than the developer work it was designed for; and so the journey to total version control began.

The first step in this process was to open a new GitHub repository devoted to this project. GitHub repositories are free and public by default, their contents, thus, are also public unless you specifically select and pay for private repositories. This may instill trepidation in some editors—the idea that anyone can view your repository and your files at any time—but in my case this was exactly what I was looking for. I wanted my edition and all of its constituent parts to be open access and available to as many people as possible, and I wanted my editing methods to be transparent as well so that I could accurately go back and describe each of my editorial decisions without fear of jumbling things in my mind. Once I set up my repository, I had to clone it to my Git Bash so that any files I added could be tracked by my computer as well as the cloud. With everything set up it was time to start adding files—I began by adding pdfs of the manuscript copies of the poems passed down to me by my mentor from our work on his Lyrical Ballads edition. Pdfs can be viewed directly in GitHub which made the next step in the editing process a breeze. I knew I wanted plain text transcriptions of the manuscripts and print editions of the poem, and GitHub conveniently provides users with an option to “Create new file”—though designed for code—in plain text, with numbered lines: a perfect combination of things for someone wanting to transcribe a poem with many lines. I began by opening two GitHub windows—one with the manuscript pdfs open and the other with the “Create new file” editor open—and simply made my transcriptions with the windows open side by side, then committed the file to the repository. If I went back and found that I had made a mistake, I would locate the option to edit the file (represented by a small pencil icon), fix the error, enter a commit message, and save the commit. Oftentimes I would do this work remotely—away from my laptop or on a public computer—and would have to come home and pull the new changes I made in the cloud into my local branch to ensure the versions were up to date. What I found was that I felt more confident than ever before in my ability to monitor and keep track of all of my work on the edition because I knew that at any moment I could refer to the commit history and know what I had done to alter the text. Also, there is something empowering in being able to work with a computer on that level; to be able to tap into the “computer’s raw power” as Joris van Zundert puts it in his chapter, “Barely Beyond the Book?” (86).

I discovered that my methodology was mainly driven by my fractured understanding of the capabilities of the interface I was interacting with, combined with a rich experiential-background in traditional textual editing. It was in the process of experimenting with GitHub and Git using something I was already very familiar with (i.e. I knew the poem’s textual history and was comfortable performing editorial tasks such as transcribing, annotating, retrieving witnesses, and collating the apparatus) that I began to understand the real potential of this type of application for textual studies more broadly, and for computational studies as well. I practiced throughout the semester, teaching myself the commands to manage my edition from any computer so that I might bring myself closer to understanding how my interactions with my computer could be fully described and referenced for study in post. I feel that I am more equipped to work with the technology—collaborators in a sense—to create fully realized, hypertextual editions than I was before I started this project.

Midway through the project, about the time I needed to begin bringing all of the pieces together in some sort of representative fashion, I began to worry about how I would host my edition. I am not currently skilled enough in computational languages to hand code a functional website—let alone one that could warrant the degree of interactivity and general aesthetic expected of modern digital editions—which rendered a GitHub Pages hosted website nearly impossible, however, I did successfully link a GitHub Pages website to the repository with an editable .yml file for future use. To circumvent this gap in my understanding of the application, I turned to other content management systems I had worked with previously to see what degree of customization I could achieve without a great deal of coding experience. I settled on creating a free Wix site because it offered the greatest degree of personalization, allowing the user to start from a completely blank, white canvas and begin dragging and dropping page-content into place. From there the construction of the site was primarily aesthetic as the technical and bibliographical information simply had to be copied from the repository into the edition website when the time came. I found, much in the style of blog writing, that it was easiest to craft my editor’s notes and commentary directly in the web-editor, and that I often worked backwards and had to input those particular aspects of the edition into the GitHub repository retroactively.

What I determined from my tendency to do this was an implicit resistance to automatically compose my own writing in GitHub. Despite my natural adherence to the application in the beginning of the process—opting to transcribe the versions of the poem directly in the “Create new file” editor—something about the general presentation of the editor (perhaps the numbered lines?) did not entice me to compose the prose sections of my edition in GitHub. What got lost when I chose to do my own writing outside of the version controlled environment were all of the personal and traceable developments in the writing process that I was working so hard to recover for Wordsworth’s “Nutting”. It was as if, in using the interface to trace the history of one author I, subliminally I think, didn’t want to introduce my own unique self-editing contingencies into the transmission. Somehow, I subverted the primary driving force of my own edition: to capture the interconnectedness of the versions for every witness which engages with the constituent parts and actors in the transmission. A comprehensive account or archive of these constituent parts weighs the editor’s contributions (i.e. commentary and notes) just as heavily as the extant versions of the work, and any edition worth its salt recognizes the whole of itself as a new work separate yet linked to those prior to it in the transmission. In failing to recognize the importance of version control for not only Wordsworth’s versions, but mine as well, I reduced the degree of versioning by an alarming degree, obscuring my editorial process from the reader—essentially appearing to be, though unintentionally, a creator exempt from error. Though presented digitally in this case, writing of this kind is inherent of print technology and not intrinsically suited to an interface as hyper-textually capable as the network.