If there's anyone around in the next couple hours, I could use another pair of eyes (and opinion) on unix.stackexchange.com/a/708247/117549; it's been flagged as spam, but it's not obvious to me, and I want to handle the flag correctly.
sure; given that they're older blog posts, not obviously-written by the U&L author, it fell a bit short for me; terdon replied elsewhere that he's used meetfranz (which I wasn't familiar with), so the spam meter is falling for me; just didn't want to miss anything
(it's possible that meetfranz was unlinked because SE blocked "too many links from a new user")
Thanks for the feedback, @StephenKitt! I've custom-declined the flag for now.
Well if I were writing a document I would probably just use google docs which also has some version history functionality that would probably suit my needs
I do version control for the future. If I want to track down a certain train of thought that might have gone lost during the development of a project, I can look in the history and see where that appears. Or I might want to see who did what and when, and to what. If you want to write about Greek food (without boiled eggs), then you could use Git to keep track of all the changes. But you could also just save new copies of the document while writing it. It depends.
What you get with Git, or with any version control system, is the ability to add comments to changes. If you write a document from start to finish, this may not be a very interesting feature to have, but it may also be a very nice feature to have if your text undergoes random changes here and there during the course of authoring it. It depends.
oh for some reason I though the main purpose was to not lose some section which you deleted and later wanted to look at again because it was good after all
@Asinomás The main purpose of a tool is to be useful. How it is useful depends on who's using it.
It may be that the main thing you learn from trying to use Git is that Google Docs is the better option for you at this time. And, well, that's a useful thing to learn too.
I'm just incredibly careful not to say "Yes, definitely, use Git!" because 1) I don't know you, 2) I don't know what you know, 3) I don't know your project, 4) I don't know your plans for your project, 5) I really don't want to to hear "Some nerd suggested I should use Git and it screwed up may project and I never ever want to work with writing or computers ever again".