I have read this post: http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th
which describes an incident where a user accidentally triggered a git push --force
from an outdated state of the repository.
Now of course this requires some clean up to restore the original state branches. But since Git never deletes information as I understand this clean up process is always possible.
So even though you rebase, push --force (and other operations that might rewrite the history) the original commits are still there they just needs to be found right?
In short are the any (destructive) operation in git that actually deletes data?
Git does delete things eventually. It auto garbage collects every "5000 objects." I am not sure if that means 5000 commits or if it refers to something else. There are ways of undoing things, although when a person force pushes from an old version of a repo can being annoying. Depending on if you delete the bad push or revert there will be garbage in your git history, but git does eventually clean up.
Commits that are not reachable via any reference will eventually be deleted, which includes the reflog. The default time period for this to happen is pretty conservative. There are several options you can use to adjust this via git config See below for some of the specific options.
A lot of people (myself included), would suggest that you setup your receive hooks to deny non-fast-forward merges, which would largely make this issue moot (on the server, individuals could still lose unpushed local work).