Comment by KPGv2
3 days ago
> I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
What you're describing is called "track changes" in word processors.
I'd say an alternative to using Git or JJ or whatever is use a version control that exists to serve non-code. That is to say, use Track Changes! :D
Word, Google Docs, Scrivener (this is my favorite), etc. have no problem telling you "hey you changed this draft by inserting a paragraph and changing this other word's verb ending, while also replacing this one with a synonym."
Yeah, if you use Git, which was designed for tracking changes to a far more limited kind of language, you're going to run into incompatibilities. So track changes with a version control created for tracking changes to human language.
If you have to "rethink" your app in order to serve a new purpose, it's a red flag that you're trying to square a circle.
Better to use a tool that was created for your purpose.
Maybe I just haven’t discovered the track changes feature in word processors enough, but I find it lacking: no explicit grouping of changes (the git commit), no clear timeline of changes, no tagging / naming of versions etc.
Not saying that a line-by-line diff is that much better. Neither is great imo.
I mean, whatever works for you. Go for it. It wasn't my intention to be prescriptive.
I don't like word processors. They're heavy and don't cleanly separate style from structure. And they use more or less obscure file formats.
I like text editors -- vim especially -- and plain text (or plain text with a thin layer of lightweight markup, like Markdown). And semantic linewrapping plus git is good enough for my purposes.
It may not be for yours, and that's OK. We are allowed to be different.
Wow, you use Word, Google Docs and Scrivener to author the content on your website? Tell me more.
The comment you're responding to is obnoxious, but authoring in Google Docs and exporting to HTML+CSS would be viable and is 10x more accessible than the simultaneously over- and underengineered toolchains and work practices that the professional web developer class has turned out, and doesn't produce output substantially worse than the now-widespread practice of sending mangled/minified payloads to UAs, which in the worst cases involves turning content into opaque blobs that you have to squirt through a JS runtime to get anything meaningful on screen.
The state of the art in Web publishing is such a mess that paid practitioners have, seemingly without realizing it, quietly eliminated the main reason why anyone should even have an expert handle the "lowering" from concept to HTML+CSS instead of using a quasi-WYSIWYG tool or some other crummy sitebuilder and working with whatever shoddy markup they give you.
berkshirehathaway.com (<https://berkshirehathaway.com/>) makes the rounds every now and then, and people ooh and aah over it in the comments, but you can tell they never really get it because then they just turn around and dump their next Vercel-hosted monstrosity on the world.