Git for Windows is Trash#

As you may recall, I find that having a dedicated writing environment is more productive. Getting this blog launched is a serious undertaking because I am building self-hosted infrastructure, while attempting to write about the self-hosed infrastructure, using the self-hosted infrastructure. It’s like writing about building a house from bricks while sitting in a house made of sticks that is actively falling down.

Why is the house falling down? Well, my idea of running a home lab works like this: hack, crash, patch, repeat. Most of the time I am half-way down the rabbit hole before I realize that I took a wrong turn at Albuquerque.

If you find yourself struggling with Git, try not using Git on Windows. Git Bash was fine when all I was doing was publishing the entire site over and over again with SCP. But once I started trying to do basically anything useful (like rsync or Python) it became clear that this was not a job for Windows. Windows is kind of a necessary evil for me, especially at work, but fortunately there’s the Windows Subsytem for Linux.

To install WSL, you do the following:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl --install

I think you can skip the dism.exe commands on certain versions of Windows 11, but I’m not sure. Once that’s done, you have an Ubuntu terminal. The species of Linux generally doesn’t matter for this project. Ubuntu is what you get by default.

Why I Went Back to Git#

Using Syncthing works perfectly on my personal laptop and my VM. It does not work well on my work laptop when I am at work. I figure that it’s some obscure networking thing. I am trying to stay below the radar, so I don’t want to fiddle with things on the network. The problem with not syncing files between my personal laptop and my work laptop is there is no Source of Truth for my writing files. This is the exact situation that Git was purpose-built for.

In my research, I learned that you can create a remote Git repository anywhere with Git and SSH. So I have built a small Linux container to serve as my staging server. Git can do all manner of things, and I will get to some of them eventually, but for now, I am building some foundational tools.

Bare Remote Repos#

A bare git repo keeps all the repo’s files in the Git database, rather than a work directory on the file system. This is great for people like me that go apeshit with the remove command. This is important for a remote repo because no working directory means no local edits and no check in/check out problems, or so I am told.

A remote repo is like having a private headless Git server without using a standalone Git server like Gitea. Since it’s just me, and my multiple websites, I figured that was the way to go. Also, you can connect to the remote repo via SSH, which I prefer over almost anything else. Any time I want a fresh copy of the writing I want to work on, I just pull it from git.

To create my bare remote repo, I connected to my staging server via SSH and installed Git. I then created subfolders in my home directory.

sudo apt install git
mkdir -p git/foo.git
cd git/foo.git
git init --bare
git branch -M main
ls
exit

I decided to put the Git stuff in a dedicated Git directory called Git, and each site into its own repo called $site.git where $site is the domain of my website. In the example above, I called the repo foo.git, but for a domain name I would use example.com.git. I created the bare git repo with the –bare flag.

To connect my laptop to my bare remote repo created a local working directory under WSL on my laptop, which I also called foo:

cd ~/writing
git init foo
cd foo
git remote add foo ssh://me@staging/home/me/git/foo.git
git checkout -b main
touch index.md
git add index.md
git commit -m "first post"
git push --set-upstream foo/main main
git pull
git push

Much like the remote repo, I decided that the local working directories should be kept in a folder called writing. I created the foo working directory. Next I created the link to the remote bare repo.

After that it’s mostly like normal Git. You can check out a branch of the code, make changes and push it back up.

Doing actual writing#

I am still using Zettlr for Windows to write. This is where the duct tape comes into play.

On my Windows laptop(s) the actual git stuff runs under WSL, so the folder I do writing in should be accessible to Windows Explorer. So on Windows, I created my writing folder (in a local directory C:\chris). Then, in WSL I created a symbolic link to the folder in the Windows file system:

ln -s /mnt/c/chris/writing ~/writing
mkdir -p ~/writing/foo
cd ~writing/foo
git init
git remote add foo ssh://me@staging/home/me/git/foo.git
git pull foo main

Now, in Zettlr, I can click “Open Workspace” and browse to C:\chris\writing.

Any time I start writing, I just go into WSL and pull the git repo again:

git pull foo

Saving my writing#

When I am done writing, and I am ready to do the build in Hugo, I do the usual Git incantation to push files back up to the git repo on the staging server:

git add .
git commit -m "new post 06/09/2025"
git push

Now that the writing is saved on the staging server, I can use Hugo to build the website. Or at least I will, once I figure that part out.

I would like to wrap this into a shell script, so I just have to type newpost.sh to pull the latest repo down and prepare an empty file. That is going to take more work, especially since I just want to mess with the markdown files, and not the Hugo build process. But those are challenges for the future.