...Eh, I thought the title was funny. I recently finished scene #13 in my wip. Obviously, because it was scene 13, things weren't going to go as planned. (If you aren't scared to death of the number 13, then... Well. I pity you. But back to our story.) I wound up deleting the last 1600 words of the scene and writing them over from scratch. Thing is, all the information in the original version is important, probably bound to be canon, and it was nice to know it. Normally, this would mean I'd need to keep a copy of the original scene around someplace in a scraps file, or at the bottom of the document, or... Wherever. This novel, however, is stored in a version control system called git, so I've already got a copy of the original scene as it was when it was committed, and I'm free to delete the thing and start over any time or any way I like. Quite pleased with that!
Speaking of git/github: I stumbled across https://www.penflip.com. As far as I understand, it's a graphical git frontend specifically designed for creative writing. Looks very interesting.
That sounds pretty neat, and it would be interesting to see if that can really make the whole distributed source control thing more accessible. Probably as a result of what I do for a living, I'm inclined to say that people should just learn to use the tool itself rather than have some other thing use it for them, but that may be a waste of time for most, huh.
I never realized fields other than software used git for stuff. Is it really all that helpful? I use git for source code that have millions of lines, but for smaller projects, I just use svn. The major advantage of git is that it's distributed, but that seems a little pointless for a personal project? Also, if you want a good GUI for version control, Tortoise seems to be becoming the standard.
The biggest impediment to getting 'regular' people to use github is the interface. Grab someone that does not use it & open a page and show it to them. probably 99% will look at you and say "Ok?". It makes no sense until you understand the hierarchy used to create the interface they use.
Well, full disclosure, I am a software engineer by trade. I don't even use a gui for git; I use the terminal. I think that it's very helpful, as a result of examples like the one I gave her. I also think distributed solutions like git or mercurial are probably preferable to centralized solutions like svn, owing to the fact that you can have the full repository on multiple machines and changes can be made independently on each. But I have never tried svn; closest I've come would have been the Microsoft solutions--TFS or source safe.
Not GitHub. Just git. But you hit the nail on the head: until you understand what is going on behind the scenes, almost none of this crap makes sense. That's why I was saying I think it's important to understand the tools rather than the gui.
git has its full glory only if you use plain text files, or some kind of add-on to make it understand the document structure. What are you using to edit the files?
S0 you write as plain text? Possibly some light mark-up coding to indicate italics or paragraph styles?
Part of that involves this script: #!/bin/zsh ls ./src/chapter_* | pubform "<name here>" | pandoc -o sacrifice.epub ls ./src/chapter_* | pubform "<name here>" | pandoc -o sacrifice.pdf "pubform" is a program I wrote that accepts a list of filenames from standard input and then streams the contents of the files onto standard output. Before it spits out the files' contents, however, it first spits out some some headers that Pandoc uses for formatting a book, including the name of the book, the name of the author, etc. The final command in each pipeline instructs pandoc to emit a file based on the data it receives on standard input. Pandoc automatically detects that it is receiving markdown and, likewise, automatically detects that it is meant to emit an epub and a pdf, respectively. I didn't write pandoc. It's quite an impressive little piece of software.
