5 ms·

It is impossible to blindly use the origin refs in that case. Git doesn't deal well with rewriting history. If someone force pushes to a centrally shared repo,

• pyre 14y ago
  From the article: | New refs are pulled down to the downstream | repository; all updates, including forced updates, | are mirrored to the downstream repository. | As a result, making a mirror clone essentially | bypasses the safety checks in the repository And > If someone force pushes to a centrally shared > repo, all hell breaks loose. This would happen to users pulling/pushing from the central repo, but not to the mirrors.
  • Confusion 14y ago
    In that case another developer would notice, would get in touch with his fellow developers, they would agree to force push a specific repository condition and all is well and back to normal. There is no need to restore anything from backups or mirrors in that scenario. So that's an entirely different threat. On the one hand we have FS corruption, which is basically bound to happen and is likely to impact many repositories. On the other hand we have someone (maliciously) force pushing an update on a single repository that throws away all commits. The first issue is one that needs a backup and restore procedure. The second is one that is at best an inconvenience and at worst a security problem. Unless you want to include the the worst case scenario someone gaining access to the machine and force pushing such a destructive update on all repos. In that case restoring from developer copies may actually be safer anyway, because the machine and all its backups, be they mirrors or otherwise, may be considered compromised. That's a nightmare for which this discussion about backups is just quibbling.