![]() ![]() ![]() So I tend to type up all the edits together and, afterwards, commit them one by one. Typing and committing are different types of activities and I’d rather deal with one and then the other. In practice, it’s a pain to stop every time I make an edit and commit it. There are big limitations with the third step. ![]() Type each edit as a separate commit, with the author date value corresponding to the time I scribbled the edit on paper.Make edits on that longhand manuscript by hand, as I reread (sometimes while I’m in stage 1).Type up my longhand draft from the manuscript, section by section, committing each one with the author date from the manuscript.So, putting to one side the initial writing process, my typing process for a manuscript has roughly three stages: Again, these edits are committed separately with their own author date values. Because I’m a little bit obsessive about seeing my process develop over time, I also note the date and time that I make these little scribbles.įinally, I go through my typed versions and make the edits on the file too. Sometimes I add words, or remove them sometimes I correct mistakes. If you’re not sure what I mean by this, there’s plenty of information about author date values vs commit date values out there.)īut as I type, I often scribble down things I want to change. (The commit date simply remains the date I’m actually committing the change. When I commit a section, I also use the author date value to record the date I wrote on the manuscript itself. So when I type up a draft from my handwritten manuscript, I tend to type it section by section and commit it to a Git repo as I go. And when I sit down to write, I often write the date and time to mark the time at which I’m working on any given section. Writing processįor much of my personal writing, I write longhand, with a pen and paper. I’ve been exploring these problems lately and trying to come up with some kind of solution. But when it actually comes to working with patches, hunks, commits… You’re forced into the line-by-line approach again. Yes, there are commands like git diff -word-diff which will show changes within a line. Git’s been designed with code in mind, and therefore its basic concern is changes at the line level. Where I differ is that I don’t think the arguments go far enough. There are good arguments out there presenting reasons for creating “atomic commits”, and I agree with these in principle. But recently I’ve been frustrated by its limitations. I’ve been using Git for a while to manage and version any prose that I’m working on (including pieces like this). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |