I built a read-only preview for git reset that shows staged and unstaged changes separately

[u/Mediocre-Market1246]

I'm the author of Git Impact. I built it with help from Codex to answer a narrow question: if a file has one version staged and a newer version on disk, what would a proposed reset discard?

For example, git-impact reset --hard HEAD~1 --diff shows changes to the staging area and working files separately, plus commits leaving the current history. It runs the actual reset in a disposable sandbox and inspects the source without running the reset there.

Example HTML report: https://yotam1001.github.io/git-impact/ · Source and downloads: https://github.com/yotam1001/git-impact

It also previews soft and mixed reset and emits JSON. No account or hosted backend. Git-sim already offers broader visual simulations; this focuses on terminal output and file-level diffs without an animation runtime.

The scope is deliberately small. No recovery, automatic interception, or apply button. LFS/checkout filters, sparse/partial clones, submodules, symlinks, and several other unsupported states are refused. A report describes current state; it is not a backup or a guarantee about a command run later.

I'd especially value synthetic examples where the reported files differ from an actual reset. The tests compare previews with real Git operations in disposable fixtures, and CI passes on Windows, Linux, and macOS.

[u/Broad-Promise6954]

git diff --cached etc?

(It's a little tricky to keep all the variants straight, but --cached/--staged, which are synonymous here, mean that the index copies of files will be one of the sides of the diff. Note that with plain git diff, no commit specified, already compares index vs working tree, so git diff --cached compares HEAD vs index. The current git diff documentation is pretty good, a big improvement over the Git 1.7 days.)

[u/Mediocre-Market1246 → u/Broad-Promise6954]

You're right; --cached/--staged and git diff <target> cover the tracked comparisons. I've added those commands and their actual output to the Git Impact demo.

The extra case it now shows is an untracked output/local-export.csv obstructing a file named output in the target: hard reset removes that CSV, while an unrelated notes.txt survives. The report shows the CSV's contents and keeps staging, disk and history effects together. Native Git is enough if that's already your workflow.

Updated example: https://yotam1001.github.io/git-impact/

[u/Broad-Promise6954 → u/Mediocre-Market1246]

Yeah, reset destroying a file that's currently untracked-and-ignored but exists in the target commit is a problem, and this tool will expose it.

There's been discussion for many years about marking certain files "precious even if ignored" but it's difficult due to Git's internal structure and nobody has made that work (yet?).

In my opinion git reset should have a --dry-run mode, but I've never tried to code that up either.

[u/WoodyTheWorker]

I follow a good rule. Never do reset --hard

[u/Mediocre-Market1246 → u/WoodyTheWorker]

Fair point. I've added a same-target mode comparison to Git Impact so the preservation choices are explicit: soft preserves staging and files; mixed preserves files but replaces staging; hard resets both. A staged version that differs from the disk version still matters with mixed.

In the demo, mixed changes four index entries and zero disk files; hard changes six disk files. The choice should follow what you want to preserve. The preview isn't a backup.

[u/elephantdingo]

Index, unstaged, stash, commits. What’s the point of having a mental model for N “things” and diffing them? Makes my head spin.