Hacker News Reader

Comment by t_mahmood | Hacker News Reader

My way used to be in the past, put bare repos on Dropbox, clone the bare repo to a real path. Done.

That way, I

1. didn't have to worry about sync conflicts. Once complete, just push to origin 2. had my code backed up outside my computer

I can't exactly remember, if it saves space. I assumed it does, but not sure anymore. But I feel it was quite reliable.

I gave that way up with GitHub. But thinking of migrating to `Codeberg`

With `tailscale`, I feel we have so much options now, instead of putting our personal computer out on the Internet.

View on HN

That doesn't work -- I've tried it.

I mean, it works fine for a few days or weeks, but then it gets corrupted. Doesn't matter if you use Dropbox, Google Drive, OneDrive, whatever.

It's apparently something to do with the many hundreds of file operations git does in a basic operation, and somehow none of the sync implementations can quite handle it all 100.0000% correctly. I'm personally mystified as to why not, but can attest from personal experience (as many people can) that it will get corrupted. I've heard theories that somehow the file operations get applied out of order somewhere in the pipeline.

Among other reasons, the sync engines of these cloud stores all have "conflict detection" algorithms when multiple machines touch the same files, and while a bare repo avoids conflicts in the worktree by not having a worktree, there are still a lot of files that get touched in every git push: the refs, some of the pack files, etc.

When it is a file conflict the sync engines will often drop multiple copies with names like "file (1)" and "file (2)" and so forth. It's sometimes possible to surgically fix a git repo in that state by figuring out which files need to be "file" or "file (1)" or "file (2)" or whatever, but it is not fun.

In theory, a loose objects-only bare repo with `git gc` disabled is more append-only and might be useful in file sync engines like that, but in practice a loose-objects-only bare repo with no `git gc` is not a great experience and certainly not recommended. It's probably better to use something like `git bundle` files in a sync engine context to avoid conflicts. I wonder if anyone has built a useful automation for that.

With bare repos? I was bit by this a few years ago when work switched to "everything on OneDrive" and it seemed fine until one day it wasn't. Following that I did tests with Dropbox and iCloud to find that all could corrupt a regular repo very easily. In the past few months though I've been trying it again with bare repos on iCloud and not had an issue... yet.

I decided to try again just a couple of months ago on Google Drive for Desktop with a bare repo. Got corrupted on literally the third push.

Good luck with iCloud!

I've had a lot of success with using whatever. A lot of whatevers can quite handle many hundreds of file operations 100.0000% correctly.

Ha. I guess for me the other whatever is iCloud, but that corrupts too.

But have you ever found a cloud sync tool that doesn't eventually corrupt with git? I'm not aware of one existing, and I've looked.

Again, to be clear, I'm not talking about the occasional rsync, but rather an always-on tool that tries to sync changes as they happen.

I was thinking of my pendrive, but apparently https://news.ycombinator.com/item?id=45714245 it also works on NFS.

Interesting, so, I will have to keep this in mind if I ever want to do it again.

What about SyncThing?

Reply on news.ycombinator.com