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 Force push could potentially do that
@martine_dowden @b0rk one day, I'll force-push to a branch under review that was edited by a colleague without me knowing about it... but it hasn't happened to me yet.
@mjambon @b0rk Yea i'm terrified of that, that is why after a rebase I usually got for `git pull --rebase` that way I don't have to force push
@mjambon @martine_dowden You can use the safer `--force-with-lease`, which refuses to force push if the remote branch has changed since you last pulled it.
@samueldg @mjambon oh that's cool, I didn't know about the hat one
@b0rk usually itโ€™s more like, git got itself (or I got git) into such a state that I couldnโ€™t recover it, so I wound up doing a fresh clone and manually reapplying the changes.
@b0rk Nope! Absolutely never! (Youโ€™d need to be trying quite hard, I think?)
@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.
@b0rk @bnut when I first started out with git in about 2007 or 2008 I really didn't understand the detached head state. I wasn't using any shell prompt integration and regularly made detached commits that I later needed to create a branch in order to retain. I'm not sure if the reflog existed back then but if it did I didn't know about it. As a result of that and a _really_ unhelpful git gc setting I blindly copied off SO I did lose some of those commits. Not really git's fault IMO.
@b0rk @bnut The worst part about that whole episode was that git gc would regularly tell me it cleaned up a lot of garbage and the disk usage really went down so I thought I was doing something really good by running git gc after every checkout (or maybe it was every pull, long time ago). Little did I know I was happily just deleting my work.
@b0rk totally : the day I crashed my btrfs partition ๐Ÿ˜…
@b0rk convoluted, but we have to be careful of this in enterprise: if you cloned with --reference and were on a branch that got deleted or orphaned from within that reference AND someone ran gc in the reference that finally deleted the objects, your repo has lost commits (and is unrecoverable)
@b0rk git didn't do it, I did it. A repo was stuck in a nasty rebase I thought was beyond repair, so I decided to replace the whole directory, including (accidentally) the .git dir, with an older copy on another disk. I thought this copy was more current than it actually was.
@b0rk was coding in one laptop and then rebased my branch on another and push forced without pulling the latest changes. No reflog due to different computers. Had to ask a coworker who was watching the repo to send me the SHA

@b0rk I've already dropped the wrong stash a few times.

I'm not sure if that counts for the scope of your question, but by far, the way I've lost the most work, was not yet committed work, using git reset --hard

@b0rk I've had a case where I had a silent SSD (or was it HDD?) corruption and lost important commits this way. It was a long time ago, so I don't remember if `git fsck` detected or not, but during normal operation it was completely silent about it.
@b0rk don't know if this counts but I have run commands outside of git that accidentally wiped .git/