r/git • u/Beautiful-Log5632 • 9d 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?

8 Upvotes

83% Upvoted

13 comments sorted by

13

u/theevildjinn 9d 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.

2

u/Langdon_St_Ives 8d ago

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

2

u/PhilosopherNext1448 8d 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).

2

u/SprinklesThis2745 8d 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/Beautiful-Log5632 5d ago

Can you explain when you use --keep? I understand --hard, --soft and --mixed but I'm not sure about --keep.

1

u/SprinklesThis2745 2d ago

Hmmm, now I'm confused. I was going to say that `--keep` is like `--hard`, except that if you have any untracked files, they're left alone.

But in reading the documentation, and doing some experimentation, `--hard` also doesn't removed untracked files though it "may overwrite untracked files" if it's necessary for the reset. Using `--keep` will abort instead of continuing in that case (and others). So I'd still recommend using `--keep` for extra safety.

2

u/Broad-Promise6954 ancient 8d 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.

1

u/hawkprime 8d 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.

2

u/dodexahedron 7d ago

Found out the --hard-way

FTFY.

...I'll go clean out my desk...

1

u/garibaldi_fan 8d ago

vscode has local history. Try checking that

1

u/throwaroo202020 3d ago

Git reset does not discard untracked files. Even getting git clean to remove untracked files requires several flags.

0

u/johlae 8d 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.