in git, what ways are there to "lose" a commit in a way that you CAN'T recover using the reflog (so that you need to iterate over every single commit in the repository if you want to find it?

The only ways I know (using git's normal tools) are:

* using `git stash drop` or `git stash pop` to drop a stashed commit
* waiting 90+ days to try to recover the commit (so that it expires from the reflog)
* explicitly deleting the reflog in some way (rm -rf .git, git reflog expire, etc)

also: have you even run into a situation where git *completely deleted* a commit that you needed? (where it wasn't recoverable with the reflog or with `git fsck`)

only interested in things that have *actually happened to you*, not "this could theoretically happen if…”

I'm trying to think about whether there's any normal way for that to happen except if you completely delete your git repository.

@b0rk if it was detached, or you have certain branch configs, then I think git gc can do it. I think similar commands can be configured to run automatically when your repo is large or slow.
@bnut has that ever happened to you? i'm very aware of git gc but what I'm curious about is whether anyone has ever had a commit deleted by git gc that they cared about
@b0rk I think I’ve had detached commits lost due to the automatic cleanup because it was a large repo. Although it was a long time ago, and I don’t remember the exact diagnosis sorry.
@b0rk Yeah, I’m fairly sure it was git prune as part of automatic gc due to a large slow repo. This thing: “Auto packing the repository for optimum performance […]".
@b0rk It was a commit I cared about, which I detached through an explicit mistake (like reset), but I pruned it due to a much more unexpected implicit mistake. I believe it was pruned when fetching to see if the lost commit had been pushed.