Hi Team,
Need help to recover files from local mistake.
Regards, Kishore N S.
Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
1. Working on a feature branch with several documentation files. 2. HEAD contained only a subset of those files (already committed earlier). 3. Created additional files locally and edited existing ones. 4. Staged the new and modified files with `git add` from the IDE (VS Code / Cursor Git extension), over a period of roughly 20–30 minutes. 5. Did NOT commit before doing other git operations. 6. Later ran `git merge <remote-branch>` into the feature branch. Reflog also shows a `reset: moving to HEAD` shortly before merge / branch activity. 7. Noticed that previously staged files were no longer in the index and were not in any commit.
What did you expect to happen? (Expected behavior)
- Staged changes should remain in the index until explicitly unstaged, committed, or discarded. - `git merge` should not silently drop unrelated staged-but-uncommitted work. - Staged files should still appear under "Changes to be committed" after the merge. - The IDE should continue to show staged files and allow commit.
What happened instead? (Actual behavior)
- After merge (and/or related operations in the same session), staged files disappeared from the index. - `git status` no longer listed the files as staged. - New files that had been `git add`ed were untracked again or missing from staging. - The IDE logged warnings like "File not found" when comparing against HEAD, because those paths only existed in the index, not in any commit. - At one point, index entries for staged files suddenly disappeared (visible in IDE Git logs). - File content was not fully lost: blobs were recoverable via `git fsck --lost-found` and `.git/lost-found/other/`, but manual recovery was required (copy blobs, re-apply edits, recommit).
What's different between what you expected and what actually happened?
Expected: staging is a safe holding area until commit; merge should not wipe it. Actual: staging was cleared without commit; IDE showed confusing errors; work had to be reconstructed from lost-found blobs.
The merge only touched unrelated paths (no content conflict on the staged files), yet staged work still vanished from the index.
Anything else you want to add:
Editor: Cursor (VS Code-based), Git extension used for staging.
Rough timeline: - Staged multiple files over ~20–30 minutes - Index entries disappeared shortly after last `git add` - `git reset` and `git merge` occurred in the same session - Recovery required copying from lost-found blobs and recommitting
Suggested reproduction: 1. Stage several NEW untracked files (not in HEAD) with `git add`. 2. Do NOT commit. 3. Run `git merge <other-branch>` or `git reset` / branch checkout in the same repo. 4. Check whether the index still contains the staged new files.
Impact: time lost reconstructing work; risk of data loss if blobs had been garbage-collected.
Workaround: `git fsck --lost-found`, `git show <blob>`, copy from `.git/lost-found/other/`, recommit.
Please review the rest of the bug report below. You can delete any lines you don't wish to share.
[System Info] git version: git version 2.54.0 cpu: arm64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh rust: disabled feature: fsmonitor--daemon gettext: enabled libcurl: 8.7.1 zlib: 1.2.12 SHA-1: SHA1_DC SHA-256: SHA256_BLK default-ref-format: files default-hash: sha1 uname: Darwin 25.5.0 Darwin Kernel Version 25.5.0: Tue Jun 9 22:28:34 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T6041 arm64 compiler info: clang: 21.0.0 (clang-2100.0.123.102) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh
[Enabled Hooks]