Does Git's Default Reflog Window Make Schema-Change Rollback Safe?

A repository that tracks schema migrations needs a defined rollback safety net: if a migration commit has to be undone weeks after it landed, the pre-change state should still be recoverable. The mechanism under consideration is Git's reflog, which records HEAD movements for a configurable retention period, 90 days by default, adjustable through gc.reflogExpire.

The open question is whether that mechanism is dependable for this purpose. Reflog entries expire once the retention window passes, after which recovery depends on already knowing the commit hash or holding an external copy. The reflog is also maintained per clone, so it only helps in the working copy where the original operations happened. Meanwhile, git reset --hard discards uncommitted work outright, while git revert requires identifying the exact commit to undo.

Does the default 90-day window make the reflog a reliable safety net for reversing schema changes, or should gc.reflogExpire be raised deliberately for migration-heavy repositories? Which rollback approach preserves recoverability when the original commit hash is no longer known?