3 ms·
To me, it sounds like the mirroring system is circumventing Git and is syncing the underlying directory structure, in which case, Git is absolutely not to blame
by mehrdada 14y ago
To me, it sounds like the mirroring system is circumventing Git and is syncing the underlying directory structure, in which case, Git is absolutely not to blame. It's not a Git reliability issue. Had they been using "git fetch" on the mirror servers to clone from the backup servers, checking SHA1s while doing so, the issue would not have happened and the corrupt files would not have gotten silently replicated across servers.
- masklinn 14y ago> To me, it sounds like the mirroring system is circumventing Git The mirroring system which git provides?
- avar 14y agoThe mirroring they were using is explicitly meant to be a fast local ad-hoc clone that doesn't do integrity checks. They used the safe version before, because they were running into problems with the integrity checks, i.e. ref deletions and non-fast-forwards. What they should have done was to write a hook or a script that did those non-safe updates manually (maybe only for some repositories, and some refs, don't want to rewind e.g. master). But instead they completely bypassed the safety mechanisms and got screwed by corruption.
- klodolph 14y agoFrom the article, > our mirroring system had bugs > Originally, mirrored clones were in fact not used, but non-mirrored clones on the anongits come with their own set of issues, and are more prone to getting stopped up by legitimate, authenticated force pushes, ref deletions, and so on – and if we set the refspec such that those are allowed through silently, we don’t gain much. A hybrid approach of a non-mirror initial clone followed by a shift to mirror mode could force the server to validate the entire repository as it packs it, so that is something worth investigating.