Fair. A Wikibook on the other hand seems more of an individual work than a shared work.
For the blog, let me get back to writing something (I can e.g. reorder the articles in main.tm) and see if it is the generation of the website that puts me off—the generation, not the writing and committing the change. Maybe it is not necessary that I generate the website myself and I had not understood, or perhaps automating that will help.
I think anybody can start a wiki book without much coordination.
We could even maybe think about supporting export of TeXmacs documents to a format which is compatible with wiki. And interact with Wikis like Wikipedia. But this would be a medium difficult project, not really something we can hope to have in a week or so.
As for the blog, on my machine generation of the website is done with a one liner:
source update-website
Let me know your impressions and how to improve the workflow. Ideally I would like to be able to manage the blog from the TeXmacs UI, including generation of the website. This could be a nice exercise.
and squash, and having to respond to error: Your local changes to the following files would be overwritten by merge: and to error: failed to push some refs to 'https://github.com/pireddag/notes.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. 
Let me write later on the rest
you are using it wrongly. You have made local changes before pulling the last revision. Either you ignore them or you commit them before pulling new changes from the remote repository. Squash is not useful for basic usage. I never used it.
Another way to simplify your life is to clone a new copy of the remote repository, make your changes, commit and push and then cancel the local copy.
I think it will always happen if you make local changes and do not commit them to upstream immediately: for example if you write half a post, then come back to it one month later.
For squash, it depends: @darcy does not like a pull request with 20 commits.
Maybe I should commit only when the post is ready, but maybe that as well is wrong.
If you want to have content which is not committed just use a different clone. When you finished your article, you clone a fresh repository, add your article and then commit. There is no need to have only one clone, you can have many clones as you like. In particular you can write new articles outside the repository.
We can also think to have a directory for “not-yet-ready” articles which will not be build in the website. This is easy, just add it to the repository. The script is only looking for articles in the src directory.
This will be done anyway when your pull request is accepted. Usually the merge will be squashed. So you do not need to do it while building the pull request.
git is the de-facto-standard in modern open source. I think it pays out to learn it a bit.
Will do that. But perhaps the “right” thing is to figure out how to merge. If I am working on a new article and the repository changes, there are no conflicts. The conflict must come out of something else, id est I am changing the local repository in a way that escapes my attention; perhaps I use source update-website and then I forget that I used it.
BTW update-website must be in .gitignore, as it must pick up the user’s Texmacs so the location of TeXmacs must be customized.
If you have unintentional conflicts then you need just to tell git to accept all incoming changes and discard the local changes.
See, e.g. https://stackoverflow.com/questions/10697463/resolve-git-merge-conflicts-in-favor-of-their-changes-during-a-pull
briefly:
git merge --strategy-option theirs
but as I told you, the best thing is to work with a clean repository when you prepare a pull request.
Or you just do git checkout . to recreate a clean state for all the tracked files. At that point you can do git pull without problems and then add your files and prepare a commit.
As for update-website it is not possible to put it in .gitignore because we want to track changes to it. Don’t modify it: just copy it in a new file and modify it to suit your needs. If the new file is untracked then will not cause problems (and you can add it to your .gitignore, but then you do not want to propagate the changes upstream).
Thanks for the suggestions and explanations. I think I will try and expand the Readme of the repository to include these indications.