Rebasing isn't really destructive. Try it: open `gitk --all`, do a rebase -i and squash all the commits together, then switch back to gitk and refresh. You'll see all the old commits still in the database, but the HEAD and master branches point at the new commits. Totally not destructive, but it does take a bit of knowledge to undo the change.
Git maintains what's called a "reflog" to help with this. It's a record of every place that every ref has ever pointed in your repository. Try it: `git reflog master`. You can even see when you did pulls, and what they merged in.
The only truly destructive thing you can do to your git database is `git gc`.
> The only truly destructive thing you can do to your git database is `git gc`.
And of course we should expect garbage collection to be destructive of information that is not garbage?
Didn't know that? Just read the man page. Whoops, it doesn't actually mention that, but it does mention that it may happen automatically at times.
So only clever people like you know archaic undocumented side effects of git's inscrutable design, except nobody ever really knows the full story because there is so much unnecessary crud to learn in addition. Clearly more can be destructive than gc if gc can be executed by other commands and triggers by repository state.
git gc be default does only prune things older than 2 weeks so to lose your recently lost commits you would have to explicitly give a prune which is today.
The information is garbage - it's no longer referenced by the current state of the repository. "git gc" just delays collection in order to give users an opportunity to restore recently-unreferenced commits they decide they wanted after all. Also, the man page for "git gc" on my system describes exactly how long commits are kept around after they're no longer referenced, what this depends on, and how to change the default settings.
Git maintains what's called a "reflog" to help with this. It's a record of every place that every ref has ever pointed in your repository. Try it: `git reflog master`. You can even see when you did pulls, and what they merged in.
The only truly destructive thing you can do to your git database is `git gc`.