Readable reflog timeline
Recent HEAD movement is presented as recovery context instead of a terminal-only list of hashes.
Visual Git recovery
Recover from reflog without panic.
Git often still knows where your branch used to point. FluxGit makes reflog entries visible so you can compare recent HEAD movement, identify a likely rescue point and create a recovery branch without memorizing reflog syntax.
The problem: lost work is often hidden, not gone.
After a hard reset, accidental branch delete or confusing rebase, developers search for commands like git reflog recovery, recover deleted Git branch or undo Git reset. The data may still be reachable locally, but the rescue path is stressful and easy to mistype.
Honest beta limit
Reflog recovery is not a guarantee. Git garbage collection, deleted worktrees, missing local objects or uncommitted discarded changes can make some work unrecoverable. FluxGit surfaces candidates and rescue branches; it does not rewrite Git's retention rules.
How FluxGit helps.
Rescue branch creation
Create a named branch from a selected reflog entry so investigation does not require moving your current HEAD first.
Compare before restoring
Use visual history and diff views to inspect whether the selected entry contains the commits you expected.
Privacy and security posture.
Reflog inspection works from local Git metadata. Recovery actions should stay local unless you explicitly push a rescue branch or send diagnostics with consent. Sensitive branch names and commit IDs are not needed for licensing or ordinary beta feedback by default.
Related features.
- Safety rails reduce the chance of needing recovery in the first place.
- Semantic diff can help inspect recovered changes when analysis is supported.
- MCP agent Git exposes read-only recovery context to agents without giving them write control.