As part of working on cani I was also using a variety of git remotes. One of the remotes was hosted on a server I have at home. Here’s how I set that up.

Let’s say the server has a project in a folder called cani. This folder has the code and a .git/ directory:

/home/user/projects/cani

We can use the above folder to clone a bare repository (can be used as a remote without causing weird conflicts):

cd /home/user/bares
git clone --bare /home/user/projects/cani
# creates /home/user/bares/cani.git

To add this bare repository as a remote to push & pull from can look like a few different ways. Here’s the remote while on the same machine:

git remote add local /home/user/bares/cani.git

Here’s how you can set up the remote when pushing from another machine:

git remote add local ssh://USER@MACHINE:/home/user/bares/cani.git

We can associate the branch main as the default branch for remote local:

git remote set-branches local main

Now we’re ready to push to our local remote!

# without any config
git push ssh://USER@MACHINE:/home/user/bares/cani.git

# if remote configured with ssh://USER@ as above
git push local  

Pulling from the configured remote:

# without default branch
git pull local main

# with default branch branch `main`
git pull local

For what it’s worth, the ssh://USER@MACHINE syntax can be replaced with any ssh config you might have set up locally.

Anyway! I really liked working with a local remote, especially when working with offsite remotes with lower uptime. Setting up a local remote made it a much more relaxing to use a remote that is maybe not always available. In my own case, the offsite remote is a small community server that is getting massively hammered by big corporate scrapers. Now I have the best of both: a local remote I can push to with no delay and an offsite copy hosted by a friend in an online community. Notably, no big tech is involved!