3 ms·

Relying on consistency checks will not save you if someone does the git equivalent of rm -rf on the master repository. There is no equivalent of rm -rf in g

Relying on consistency checks will not save you if someone does the git equivalent of rm -rf on the master repository. There is no equivalent of rm -rf in git. If you remove files being versioned and commit them, the previous version still exists and the commit can be reverted. If you remove the metadata, no sync can happen, you are immediately warned (assuming good monitoring was set up) and can restore from one of the clones. If the entire machine crashes and burns, you whip out your git-server-create.sh, which provisions a new VM and restores from one of the clones. There is no additional data to be backup up with git. Any single developer with a recent clone of the repos can setup a new master git server.

tomp 14y ago
git checkout master git reset --hard HEAD^ git push --force origin master will remove the latest commit. If the mirrored repositories then blindly use the origin's refs, and do a `git gc`, the latest commit will be removed.
- Confusion 14y ago
  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, all hell breaks loose.
  - 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.
- gcb0 14y ago
  I mostly rather Hg over fit because with Hg it's way harder to "rewrite history", among other things.
  - gcb0 14y ago
    *git
- dunham 14y ago
  Doesn't `git gc` keep stuff pointed to by the last 30 days of the ref log?
  - pja 14y ago
    There's no reflog in bare repositories.

tomp 14y ago

git checkout master git reset --hard HEAD^ git push --force origin master will remove the latest commit. If the mirrored repositories then blindly use the origin's refs, and do a `git gc`, the latest commit will be removed.

Confusion 14y ago
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, all hell breaks loose.
- 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.
gcb0 14y ago
I mostly rather Hg over fit because with Hg it's way harder to "rewrite history", among other things.
- gcb0 14y ago
  *git
dunham 14y ago
Doesn't `git gc` keep stuff pointed to by the last 30 days of the ref log?
- pja 14y ago
  There's no reflog in bare repositories.