3 ms·

Can someone say more about this? I've heard of this issue before but haven't experienced it myself. How does it arise, I.e. what's the race condition between g

• Groxx 3y ago
  Git mutates files to do many of its normal operations. Dumb-syncing without being perfectly up to date before you disconnect and switch to another machine and start making more changes means you risk conflicts (new conflict-named files in Dropbox, silently clobbered changes in many, etc), and git has essentially no way to notice this and warn you about what happened or recover what you lost. So you do your stuff, later discover the sync error when you reconnect, and now you have to choose losing data or understanding git's plumbing and raw data well enough to save both by hand. --- For example, branches. From what I can tell (I'm moderately confident here, but definitely not 100%): Git stores branches as a file at .git/refs/heads/branch-name which contains the current commit SHA. When you make a new commit in that branch, it modifies the file's contents to contain the new SHA. Syncing a conflicting change here means... well lots of possibilities. Maybe one write silently wins and the other SHA gets silently garbage collected eventually, maybe there's now a new branch with a conflicty name, maybe you have a broken file because it contains a `diff` conflict and it has <<<===>>> markers, maybe demons erupt from your nostrils. Jujutsu stores branches as a folder at some/path/branch-name/. The current head of the branch is a file in that folder with the SHA as its filename (the file is empty), giving you some/path/branch/c0ffee . If you sync changes from somewhere else due to concurrent changes to your clone, it either agrees and there's no harm, or it becomes a new file in that folder, some/path/branch/00f . Your local tool doesn't know which is correct, but it can tell that a conflict occurred, and both actions' results are still available. --- That's a thing you have to design carefully around, so it's completely understandable that it's not the default. But one of the benefits is that it means you don't need special protocols to exchange data, so tons of things simply work correctly without further effort. Git has to use lock files to protect its internals, and they have numerous issues and are completely useless in some situations (e.g. NFS, Dropbox). Jujutsu simply doesn't need them, and works safely regardless of your system or usage patterns (for this at least, dunno about everything). All this^ is why I pay to store my git repos in a git host rather than simply using my own backup systems (and why I don't have two remote backups). And it's why I avoid SQLite for much of my heavy-use personal backed-up stuff - it makes one large file that mutates, so fully syncing is a MUST before making any changes. Same with keepass - one large mutating database (but it has pretty good database merging built in, so the dozen or so conflict files I've gained are easy to resolve). There are pros and cons to splitting things up into a million files of course, but I run into sync issues pretty regularly so that's the pain I feel most keenly.