Discipline is one of those things I struggle with. The biggest is how I use source control for both my programming and my writing projects. As we start to implement Git at works, some of my lazy habits at home are becoming more (painfully) obvious.

Noise

I commit a lot, mostly at the end of a thought. So, once I finish a chapter or a good scene, or write a series of methods and tests, I'll commit locally. I don't always give "good" messages for those commits, but enough to give me a hint of what is going on.

Checking in so I can move downstairs.

The problem with this is noise. There are a ton of check-ins that don't have useful comments. After a day or three, I won't care about those comments since they are basically just a progression to figure out something.

In the past, I usually worked on the master branch and cringed at the noise. Occasionally I would rebase to squash them down so I don't have quite as much noise, but overall I just suffered with them.

Seeing it differently

With the migration to Git at work, I realized that I need to actually use branches more effectively. Noise commits aren't so bad if they are put into a task branch and then later squashed once they get to the master root. So, I don't have to worry about going downstairs if I know those will be collapsed into a single useful commit later.

It also lets me work without too many restrictions during the creative process. Which is good since I find committing frequently to be critical to my process.

Where to put it

Now, the really big question is where to put it. I'm normally not fond of airing my "dirty laundry" as it were. I figured no one cares if I'm switching computers during the process and I don't blame them.

However, if I'm working between two machines, it seems silly to create an entirely different repository purely for the purpose of working between machines. This came up while working on the Fedran fonts.

At the moment, I decided to take a chance and just push it up to Github. There is going to be noise but it won't be on the master branch. I might prefix the branches with "drem-" to indicate they are task branches.

This lets me take advantage of Github's ability to manage branches but also to let other people join in (in the unlikely chance someone wants to help me work on something).

Novels

Since I also recently started my next novel (WisCon has a deadline for the writing group on the 15th), I decided to explore this process with the novel. I'm doing most of the work on the 'sal' branch because novel writing is pretty much independent of everything else I write. Same with the commissions and other WIPs (which I have a number of them).

Doing it this way means I can put novels in their proper place in my directory tree as a WIP instead of a dedicated folder. It's a minor thing, but I like the Fedran stuff underneath the "moonfire/fedran/" directory instead of in the "wip/" folder.

Markdown

I'm planning on switching my entire writing repository over to Markdown within a few (mumble). I need to finish a little bit of programming, but I already have the Perl script to do the conversion. If I go with this approach, then I can easily create a "markdown" branch and do the conversion until everything is ready to migrate.

The biggest hangup on the Markdown conversion is a good conversion to DocBook. I have the beginning of one in my writing tools, I just haven't finished it yet. It needs to be done so I can integrate the new code into my workflow.

New ideas hurt

I think the branching model will work out, though it feels strange. I just don't know if the strangeness is because I'm not used to it or because it is wrong. I think I'll have an answer in a few months.