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]

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.