Syncthing and Git: syncing a repository between computers

Short answer: Syncthing can copy a Git repository, and it often looks fine when only one computer uses it at a time. But Syncthing copies files one by one. It does not know that a commit, checkout, or rebase changes many files in .git together. Git's own FAQ says not to sync any part of a repository with a file-syncing service. Use Git to move history, and move unfinished work deliberately—or use a tool built to move it as Git state.

Three kinds of data in a repository

The first two are easy. The third is the problem. It is several files that Git updates together, and it only makes sense as a set.

Why a live .git folder is not one object

One git commit writes new objects, updates a branch ref, rewrites the index, and appends to logs. Syncthing notices each file and sends it on its own schedule. If the other computer opens the repository before every piece arrives, it can see a mix that Git never created.

Git's FAQ puts it plainly: cloud syncing services "sync file by file on a continuous basis and don't understand the structure of a Git repository." It warns this can cause missing objects, broken refs, and data loss—worst when a sync happens in the middle of a Git update. This does not mean every synced repository breaks. It means nothing in the setup prevents it.

It gets worse when both computers have work. Syncthing resolves two edits to the same file by keeping one and renaming the other to a .sync-conflict-… copy. For a source file, that is annoying but readable. For a branch ref or the index, Git has no idea the "other" version exists. Commits that only one side had can become unreferenced and later pruned.

The normal workflow: commit, push, pull

If your work is committed, you don't need Syncthing for the repository at all. Use a remote:

# laptop
git push origin my-branch

# desktop
git fetch origin
git switch my-branch

This is always the safest path. The catch is unfinished work: the staged change, the half-written file, the stash you meant to come back to. Many people make a throwaway "wip" commit just to carry it across.

A tested handoff for unfinished work, using only Git

Git 2.51 added git stash export and git stash import. They let you push stashes through a normal remote. We ran this on Git 2.53.0 on September 28, 2026, with a laptop clone and a desktop clone of the same repository.

The laptop started with four kinds of unfinished work:

$ git status --short
 M README.md      # unstaged edit
M  app.js         # staged edit
?? todo.txt       # new, untracked file
$ git stash list
stash@{0}: On main: older idea

Stash everything, export the stashes to a branch, and push it:

git stash push --include-untracked -m "handoff"
git stash export --to-ref refs/heads/stashes
git push origin stashes

On a clean desktop checkout, import and apply:

git fetch origin +stashes:stashes
git stash import stashes
git stash apply --index stash@{0}

The result matched the laptop:

$ git status --short
 M README.md
M  app.js
?? todo.txt
$ git stash list
stash@{0}: On main: handoff
stash@{1}: On main: older idea

The staged edit stayed staged (that is what --index does), the unstaged edit stayed unstaged, the new file came across, and the older stash came too.

Limits. It is manual: you have to remember to do it before you leave the laptop. --include-untracked will also carry any untracked secrets, so check git status first. And the stashes branch on your remote now holds your unfinished work—delete it when you're done.

What happens when both computers have work

We repeated the test after first editing README.md on the desktop. Git refused to apply:

$ git stash apply --index stash@{0}
error: Your local changes to the following files would be overwritten by merge:
	README.md
Please commit your changes or stash them before you merge.
Aborting
Index was not unstashed.

Git protected the desktop's edit. But the refusal was not all-or-nothing: the untracked todo.txt had already been written. A second attempt then failed with todo.txt already exists, no checkout. So when both sides have work, commit or stash the destination first, apply onto a clean tree, and check git status after every step.

Syncthing has no equivalent refusal. If both computers edit the same files, it keeps one version and saves the other as a conflict copy—inside.git too.

If you keep using Syncthing

• Sync working files, but leave .git out with an ignore pattern, and move history with git push/fetch.
• If you do sync the whole repository, use it from one computer at a time and wait for Syncthing to show "Up to Date" before switching. That is a habit, not a guarantee: editors, git gc, and a laptop waking up can all write while you're away.
• Keep a real Git remote as your backup. Run git fsck if a repository starts acting strangely after a sync.
• Never bulk-delete .sync-conflict files inside a repository until you know which version each one is.

When rbox is the better fit

rbox is built for the case this page is about: you want your unfinished work on the other computer without doing the handoff by hand. It never syncs .git as files. Working files sync as encrypted files, and Git state—branch, HEAD, index, your latest stash, and an in-progress rebase or merge—moves as a git bundle.

It also covers the "both computers have work" case. If the receiving repo has its own unsynced work, rbox pauses Git sync for that repo instead of overwriting it. rbox status says so:

⚠ 1 repo is waiting on you — rbox paused git sync there so nothing you did gets overwritten.
  See them:  rbox status --git

rbox status --git then gives the reason in plain words, such as "you have uncommitted work here" or "you have stashed work here (git stash)".

You then choose: rbox git resolve <repo> show-me to see what's waiting, keep-mine to keep this computer's state, or take-theirs, which first sets this computer's Git state aside in .rbox/git-quarantine/. See the docs for the full command.

Syncthing is still the better choice if you want free, self-hosted, peer-to-peer sync, Windows or Android support, or sync for more than code. rbox is a paid, hosted service for macOS (Apple silicon) and Linux. The rbox vs Syncthing comparison covers that choice.

Keep your unfinished work available on your other computer. Install rbox and run rbox setup, see pricing, or read how to sync code between two computers.

Official references

Git FAQ: How do I sync a working tree across systems? · git stash · Syncthing: conflicting changes · Syncthing: ignoring files