12 hours until I have to decide if I dare do nanowrimo

[jack]

12 hours until I have to decide if I dare do nanowrimo. My head is filling with worldbuilding ideas, but no plot. Are fictional encyclopedias a thing yet?

More seriously, I'm less rushed off my feet than most years, but I'm busy with lots of stuff, I'm not sure I can devote enough time this month to writing a whole novel. But I do want to devote more time to blitzing on a hobby for a little bit, especially ones where I have something to show for it afterwards.

Who ended up doing yuletide this year?

Is anyone trying NaNoWriMo?

(Usual disclaimer: Every year when people talk about nanowrimo someone gets really defensive and says "everyone who does NaNoWriMo thinks a 50k word unedited novel is a path to instant published success". I don't know anyone who thinks that, if you want to debunk that idea, please go find someone who believes it and don't try to persuade me :))

Comments

[seekingferret]

Also, to combine the subjects of two of your recent posts, if you do end up doing NaNo, I'd be interested in your approach to revision control. Last year was the first time I set up a git repo for my NaNo story, and I'm doing the same again this year, but I'm not a programmer and I'm not entirely sure I'm doing my commits in a way that will make them useful to me while editing.

[jack]

Good question! I'm not sure, I think that's a really good thing to do but I've rarely actually done it. As long as you're committing as all I think you're getting most of the benefit. I think I'd commit reflexively whenever I'd written something I wanted to make sure I kept, but specifically before I did any big deletions. I've no experience when it might be useful later, I think the main benefits would be: (i) able to backup and share between computers and not get conflicts between slightly different changes (ii) if you delete a bunch of stuff that's not working, it's not cluttering up your directory, but if you ever want to see what was in it later you can (iii) you can have commit comments describing the changes you make

Basically, just keep it git and see what turns out to be useful later is probably better -- most people probably still use unversioned unbackedup word documents :)

[seekingferret]

Yeah, those are more or less my reasons, plus (iv) If I send a draft to a beta reader and it takes them a while to get it back to me, I can keep writing/editing myself and easily be able to compare their notes to the older version I sent them and (v) theoretically I can branch if I want to try out a major revision that I'm not sure will work, though I don't know if I would ever really do this.

[jack]

Oh yes, merging slightly different revisions is really useful. It may not come up immediately but if it does it's really useful. That may indeed be fiddly, but you probably don't need to do anything in advance.

Comments from reviewers on an out-of-date draft is a really good example. As is "I was travelling and did a bunch of work on an old revision by accident". git merge may just be able to automatically work out the new bits of each.

[seekingferret]

Yeah, my main worry is that there are features of git I'm not aware of that would do useful things for me if I knew them.

When I read your discussion of first-parent and all of that, I followed enough to say "I think he's talking about working in a multi-user development environment and how to maintain a useful rev history when features are being merged from multiple places, so it's not really relevant to me." But I could have been wrong.

[jack]

Oops, sorry. Yes, yes, yes, ignore all that completely.

What you already know is plenty to be going on with, and is already 80% of what most programmers would need to know about git day-to-day. The concept of different branches is not that complicated, but only really important for projects with more files/more people.

I don't think there's anything obvious you're missing. As long as you're committing regularly at all, I think it will become obvious which turns out to be useful later.

My last post was more about "this is how I think source control should work, but no existing source control systems actually do this". Except I failed to convince even the git experts, so it was probably not going anywhere. It's not relevant information for anyone else, unfortunately.