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

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 Syncthing VM. It does not work well on my work laptop. 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 problem that Git was purpose-built to solve.

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 area. Git can do all manner of things, and I will get to some of them eventually, but for now, I am building some of the foundational tools.

Bare Remote Repos#

A bare git repo keeps all of the repo’s files in the Git database, rather than a work directory on the filesystem. 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 Git server without running a 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.

To create my bare remote repo, I connected to my staging server and installed Git, 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://chris@staging/home/chris/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.

The WSL filesystem is accessible from Windows. It behaves like a hidden network share located at:

start \\wsl$

This should pop up an explorer window that lists your Linux distributions (it’s usually Ubuntu, but there could be more). This can be mapped like a Windows network drive:

net use u:  \\wsl$\Ubuntu /persistent:yes

This will map a network drive to U: I found home directory by going to u:\home. My WSL Ubuntu username is ‘chris’ so my home directory is /home/chris

U:\home\chris\writing is the place where I created my Git repo. Now I can open the ‘writing’ folder in Zettlr and do my thing. LOL, there is a little Linux icon in Windows explorer. Use that instead. I’m old and I’ve been using Windows for a long time, but I use the run line and cmd shell for just about everything. It’s fast, and it’s handy for when Microsoft moves the button for something important.

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:

git add .
git commit -m "new post"
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.