How do you store / backup / track changes for your writing? I've been just periodically copying everything to another location.

I write all my fiction in Markdown format. That way, git stores revisions very efficiently, and allows them to be diffed.
You can then use pandoc, and a template file, to generate a LibreOffice document, which can be turned into a paperback or an e-book.
For novels, title 1 is for chapters, title 2 is for scene breaks within chapters, and I use blockquote for occasional poems and song lyrics.
pandoc supports Markdown extensions. fenced_divs can be mapped to paragraph styles, and bracketed_spans can be mapped to character styles, making it possible to store screenplays as Markdown in git.
I tell you all this, even though literally no one is going to respond.

>>24553782
>very efficiently,
I'm not so sure about that. My git repo for my manuscript has reached 1 gig "already."

>>24553790
Is your manuscript in a text format, or a binary format?

>>24553805
it's pure txt

>>24553840
Is your novel all one line or something? git's compression is line-by-line. Because it's inconceivable a single novel has somehow led to a 1 GB git repo without some serious pathology. Even the git repo for CMake, a large project written over many years, is only ~113MB.

emacs, magit. simple as.(1) You can directly output epubs and pdfs too with pandoc latex and what have you

(1) 3000 hours of config tweaking not included

>>24553872
They might have done pruning and optimization.

>>24554011
My memory is that the repos I deal with at work are of similar size, and I'm positive we don't prune and optimize those. Seriously, what does your repo's filesystem look like? Are you storing revisions using the same name, or are you checking in renamed copies every time? Have you tried the sort of repo pruning/compaction techniques outlined in https://stackoverflow.com/questions/28312439 ?

>>24554023
Thinking about it, the reason I think is that with code, you are not changing the line over and over again. If it passes the test, it's done. With fiction, you are constantly editing, so the lines are continually changing. I think that's what blows it up. I'm not too worried about it right now because it's pretty much near the end of the project, so it'll end up around 1gb in size. This was also a relatively massive manuscript.

I write on LibreOffice, so of course I save all the files to my computer. I also have an external hard drive that I periodically back up all my document files on.

Also, I know it probably drives the /g/ guys nuts, but since I have a Windows computer I'm actually pretty grateful for Microsoft OneDrive. It once basically saved my life when I lost a computer due to a spill, and OneDrive had all my document files up to date, and ready to come back up on my new computer as soon as I got it.

>>24554032
You're thinking of production code, not the R&D I'm involved with. Your novel would have to be the size of Proust's In Search Of Lost Time, otherwise what you're relating makes no sense to me at all.

>>24554023
>what does your repo's filesystem look like?
I have the manuscript split up into 3 files (totaling about 1.5mb). I also have a large file (6mb) consisting of excised text. Then there are various small files that have been there for a while and that don't get touched.

>>24553790
Personally I think that’s neat because it’s so big
…even though I wouldn’t want to run git clone from my laptop on my phone data plan for it
>>24553782
Have you dug through your Git history to find anything, or are you only getting peace of mind from having the history around?

>>24554046
Microsoft will nag you to use it but they’re not totally wrong to do so

This is a retarded practice--I would even go as far as call it juvenile. It sets a bad precedent, making you value half-baked work. Either discard everything or publish it, writing isn't code.

This is a retarded practice--I would even go as far as to call it juvenile. It sets a bad precedent, making you value half-baked work. Either discard everything or publish it, writing isn't code.

>>24554032
We do plenty of writing documentation in git repos at work. I don't see such problems at all. Your setup is somehow really messed up.
>>24554392
I have a feeling you've not published much. I'd be happy to be wrong, but in my experience, perfectionists don't ship.

>>24554572
I am published and this has nothing to do with perfectionism. The issue is thinking that abandoning the discarding of sub par drafts as was common during the typewriting era for the adoption of coding tools because of their convenience makes for better writing. Coding tools have versioning for a reason that is completely removed from what writing is supposed to be--professional tracking of changes vs unfettered expression of thought.

>>24554593
> The issue is thinking that abandoning the discarding of sub par drafts as was common during the typewriting era for the adoption of coding tools because of their convenience makes for better writing.
Can you explain the issue better? If you have a chapter, and you're fine with it but one particular dialogue or scene is weak - how does discarding the rest of the chapter help?

>>24554611
Discard any part you are uncomfortable with. The more you do it and kill this recently manufactured fear of hoarding digital experiences, the better you become at writing what you are comfortable with. The simple fact is that using these tools prevents you from doing more writing. You can look at all the previous versions you've saved and convince that you've done enough writing.

A simple git guide I used in uni for anyone interested.
>https://rogerdudler.github.io/git-guide/
There's another thread on this topic >>24550812, I feel like a "Unix for writers" book might be cool feels like there's some interest.

>>24554593
>I am published
X
Captcha: N0PDNA

>>24554111
Then I have no explanation, and can honestly say I haven't run into your problem. The git repo for my fiction is ~7 MB, and that includes over 100 short stories. Have you tried "git gc" or not? Did you even look at https://stackoverflow.com/questions/28312439 ?
>>24554325
No, I've dug through my git history, looking for text I cut out of something, when I decide to use it somewhere else.

>>24553805
>>24553872
You do know he's trolling you, right?

>>24554969
>100 short stories
what is the total file size on these?

>>24553663 (OP)
I write directly in TeX and use git for version control.
Each chapter is divided into a different file which is then called by the main document for compilation.

I've experimented with Markdown and Pandoc like some other Anon's have recommended; however, I find that Markdown lacks a lot of the control that I'm familiar with -- it just isn't verbose enough.

>>24555782
If you're not going to run "git gc", nor explain why you won't, then I'm done with you.

>>24556792
holy smokes! it worked. what the hell? it went down to like 53mb!

now how do i get my remote to the same size?

>>24554619
It's not about hoarding digital experiences, it's about making smarter, more thoughtful changes that you can later refer back to

One of its greatest strengths is in fact not hoarding, but discarding. With version control it is substantially easier to experiment, prototype, get weird. It takes a few seconds to branch out, and just as fast to throw it away if it's not working. better yet, you can switch back and forth between what you're confident with and what you're playing with over hours or days or years, and at the end you can merge them together with the click of a button

It may seem anti-art because the dastardly comp sci majors use it, but it's a very useful and will make you a better writer

>>24555926
You may like https://djot.net/ — it’s by the Pandoc guy who’s been tearing his hair out for ten years or so trying to reimplement a Perl script (Markdown.pl) in a bondage-and-discipline language (Haskell)
>>24554619
I think your concerns are overblown
It’s not like your old text is still around and cluttering things
Digging through my Git history is more like dumpster diving
If I wanted to keep track of maybe-interesting deleted sections I’d have to, like, make Git tags for interesting removed parts or ask an AI to run through it all and suggest commit hashes for stuff that looks like the thing I deleted that I might want to resurrect

>>24556840
Ugh. Why didn't you take my advice when I first gave it, a day ago?! You have to remember that git was designed by Linus Torvalds for the purposes of Linux kernel development; it is not, and never will be, idiot -proofed. As for how to do that in your remote repo, what is the nature of your remote repo? Is it on a different machine, running through a git server, or is it a directory on a thumb drive? If the latter, just cd into that bare git directory and run "git gc".

>>24557337
>Ugh. Why didn't you take my advice when I first gave it, a day ago?!
haha! i should have. didn't think it would make such a dramatic difference. thanks though. i appreciate it.

>what is the nature of your remote repo?
it's on a hosted service that i only acccess via their web app. maybe i can just delete it and push my local repo?

>>24557345
No, don't delete your remote repo. In all likelihood, they're doing proper auto-compacting on it, and you don't need to do anything. It was just your local repo that had never received proper housecleaning.

>>24557355
No, it's huge.

If you're using git for tracking book progress and not for other purposes which usually involves a team, in my opinion, it's much better and hence intuitive to use fossil-scm

You guys are really overcomplicating the draft process.

Not digitally, that's for sure.


(notesnook and proton drive, sometimes)

>>24557457
That's up to your git service provider. Are they complaining about the size of your repo or something?

>>24553790
That's definitely not efficient.

>>24558196
Yeah it's hitting the limit for their free tier

>>24557487
Yeah but there are lots of great GUI tools for GitHub and GitHub alone
I’m OK at the command line but I like VS Code’s GitHub tooling and I’m also a happy Tower user

>>24559092
You'll have to ask them why they're not running "git gc" in their hosted repos.

all handwritten first drafts and sometimes i transfer to an offline computer. if i ever write something straight on the computer for the first time (when i'm transferring notes) i label it as such and when i go back and look at such things they're typically awful

>>24559092
You also may want to consider create a "bare repo" on a thumb drive or something, and adding that as a new remote. Then you can push your repo locally & have another backup.

>>24553663 (OP)
Typst + Git + VS Code

Amazing combo if you know a bit of rust and can program your own functions. Nothing comes even close to it.