Git for Writing or other Non-Coding Projects?

Although this is almost enough to convince me not to start using git (for prose), I’d still like to better understand the short-comings. Apart from the problem of paragraphs being long lines for git, my impression is also that git diff (and pretty much any diff tool?) struggles with larger insertions. (But I may not have understood how to use it.) What I mean is that once you insert a larger chunk of text, whatever comes after that insertion will show up as modified, even though it wasn’t changed at all.

From what I understand, this is because git diff operates on a line by line basis and doesn’t have a large context window that would enable it to notice that a piece of text isn’t actually new but just moved down. I read that git diff --patience tries to remedy this, but I haven’t tried it and I’m wondering whether it is worth trying in the world of prose.

Git just versions files. It excels at plain text i.e. source code and markdown.

You can use any diff tool you like. I use BeyondCompare and it does a pretty good job of getting differences down to a few characters.

However, rather than take the advice of anyone here, run a small safe to fail experiment. Maybe you will like it, maybe not.

Since I last wrote in this thread we’ve switched our entire website development to astro/markdown/mdx. See: https://agilepainrelief.com

I’m the ideal target audience for this - I’m a recovering software developer.

3 Likes

I’m thinking the obsidian git plugin might be a good way of trying out git.

When I first tried git a few months ago in an attempt to share some R and Python code (for data analysis) with a colleague I used git cli commands and found it rather laborious. Part of it may be me climbing the learning curve while what I really needed to do was analyze data, but I sensed that even if I eventually learned the important commands (and understood the overall logic of git) git would still feel like a burden rather that something making things easier. But if the obsidian plugin does most of the version control in the background, it would actually relieve me from overthinking which notes I should split or not split and to what extent I want to document a note’s history…

I’m using git with Obsidian on 1 vault but NOT using the git plug-in. I am a git novice but I found it much faster and easier to just learn the minimum git command I need and run them from the command line. There are really only a very few you actually need to learn to function quite well.

The Obsidian git plug-in only handles an entire vault and the vault I am using has 2 main sections, the database schema creation code and the support technical documentation. So I put those things into 2 separate folders and set each folder as a git instance pointing to a different repository on GitLab (we don’t use GitHub). Works well and we are also syncing that vault to all team members via Obsidian sync.

Meant to call this out for further discussion above and messed up…

There are really only a few things you need to learn about git. This is my personal summary and my personal git cheat sheet.

Using Git

  1. Git saves everything you commit and push
  2. Fewer branches is better
  3. Rebase can be your friend but can also mess you up so use with caution
  4. Git commands do not all use the same syntax, deal with it
  5. The ProGit book is excellent Git

My Git command cheat sheet

git remote add upstream https://…

use the https clone location from the upstream site

git remote --verbose

shows all the remotes you have

git status

Tell me where I am with my local on-mac repo

git fetch origin

This pulls things down but does not merge them into my system. They are just available. If you only have one remote that is origin the command is just git fetch

git pull origin branchname

do a fetch then merge operation if you only have one origin and you have checked out the branch you want already then you only need to do a git pull

git checkout branchname

git checkout -b hcase/feature-branch

Create and checkout a feature branch based on the branch you are at. We use a person’s name as a directory and then the feature branch as it makes the commit history cleaner. This one is for a feature branch that Henry Case is working on. (yes I have read Neuromancer)

git add <modified_file_names>

Stage changes for commit

git commit -m"a short description of your work"

puts changes into your local system

git push

push your feature branch to GitLab

Create a merge request in Gitlab.

- Make sure the source branch is your feature branch.
- Make sure the destination branch is `develop`

I also found that of the visual tools you can use GitKraken has the most understandable picture of the git tree on your repositories. But I don’t use it to do any repo work just to look at what the state of the repo is.

1 Like

I agree, it creates an undesirably complex workflow without adding any real advantages. Pages and Time Machine have you covered.

I use GitHub for coding but would not use it for writing, neither group or individual work. It only really shines when built into an IDE like Jetbrains, as they have an awesome AI that writes commits for you and everything is automated (no going back to 1980s style terminal commands required!)

You would more likely spend days tweaking it to make it work for a purpose it’s not designed, and not get any writing done!!

1 Like