r/git • u/Beautiful-Log5632 • 12h ago

Uncommitted files after a hard reset

git reset --hard discards changes including untracked files and git reflog can restore the tracked files not untracked. Is there a way to get untracked files back or are they lost after a hard reset?

5 Upvotes

78% Upvoted

7 comments sorted by

9

u/theevildjinn 12h ago

Not using git, no.

If this has just happened to you, and you happen to be using a JetBrains IDE, then you may be in luck - Local History keeps track of basically every file change in the project workspace, whether it's under version control or not.

1

u/Langdon_St_Ives 11h ago

Backups. Not from the repo. You just literally told it you're ok with this by using that switch.

1

u/PhilosopherNext1448 11h ago

Some IDEs have their own version control of files, so there's a chance of getting them back, though not sure what happens when you delete a file outright. Otherwise you could use a disk scanner that scans your harddrive for deleted files and recovers them (when you delete a file, you just mark that memory on the harddrive to allow for it to be overwritten, you don't physically erase it).

1

u/SprinklesThis2745 9h ago

It won't help you right now, but for future reference, you can use `--keep` instead of `--hard`.
https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---keep

1

u/hawkprime 9h ago

Found out the hard-way long time ago, way before git. Now I have a bash script that hooks on all my save events and computes a diff and stores it in a zip file, not to mention hourly snapshots with Btrfs and of course daily off-site backups.

1

u/Broad-Promise6954 ancient 8h ago

If a file is actually untracked and not in the commit to which you are resetting, Git won't wreck it.

If it is in the commit to which you are resetting, it becomes tracked and Git will replace the working copy with the one from the commit. Because it's currently (before the reset) untracked, i.e., not in Git's index, Git does not have a copy of the copy that is/was in the working tree, and you will have to use other tools to get it back.

0

u/johlae 12h ago

https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified

It’s important to note that this flag (--hard) is the only way to make the reset command dangerous, and one of the very few cases where Git will actually destroy data. Any other invocation of reset can be pretty easily undone, but the --hard option cannot, since it forcibly overwrites files in the working directory. In this particular case, we still have the v3 version of our file in a commit in our Git DB, and we could get it back by looking at our reflog, but if we had not committed it, Git still would have overwritten the file and it would be unrecoverable.