0

Recently, I staged many changes in over 100 files. Then, unfortunately, I did a checkout of a previous commit. After the checkout all my changes are gone and not visible anymore (I'm using Fork to work with git). Are my changes really lost or can I recover the changes anyhow?

Please help!

Lars
  • 920
  • 1
  • 14
  • 34
  • 4
    If you really didn't commit or stash, then yes, your work may be lost. If your editor or IDE supports a local history, then you might be able to recover the work there. – Tim Biegeleisen May 13 '21 at 08:54
  • @TimBiegeleisen thx for your answer. It's so strange because I didn't got any warning. – Lars May 13 '21 at 09:03
  • ...and that's the worst possible outcome. At least if you had been warned that your changes would be dumped, it would have been on you. – Tim Biegeleisen May 13 '21 at 09:05
  • 2
    What was the command you used? Git doesn't generally allow a checkout if unstaged changes are to be overwritten. – evolutionxbox May 13 '21 at 09:13
  • @evolutionxbox I was working in VSCode and staged all changes (using the GitLens extension). Next I double clicked on a commit and this commit was checked out (no message or warning). The previously staged changes are not shown anymore. – Lars May 13 '21 at 09:15
  • 2
    @Lars that sucks. I think git itself would have warned you if the command line has been used. I don't know of any GUI which does? – evolutionxbox May 13 '21 at 09:17
  • @evolutionxbox thx for your condolence :-( I should start using git with the cli... – Lars May 13 '21 at 09:20
  • 2
    Given that you're not using the Git CLI, all bets may be off here. However, if the files were `git add`-ed in Git-CLI terms, the *data* for each file is in Git. *Finding* that data is the tricky part. You can find *dangling blobs* using `git fsck`; adding `--lost-found` to the command line makes Git copy the data out to files named by hash IDs, in `.git/lost-found/other/`. Figuring out which dangling blob data file corresponded to which original file is *hard*. Often it's so hard as to be pointless: it's easier just to reconstruct the files by hand. But it might help. – torek May 13 '21 at 10:21
  • 1
    I already answered [here](https://stackoverflow.com/a/58853981/717372) how to recover staged files. Other answers are also interesting. But are you sure your changes have not been stashed? – Philippe May 13 '21 at 11:54
  • @Philippe your solution seems to work well, but is it also possible to limit the the "lost-found" creation via a timestamp, e.g. show 'lost-found' between two dates? – Lars May 13 '21 at 12:11
  • 1
    As it is based on `git fsck` that does not provide this type of option, no it's not possible by default. You could still convert the command in a real shell script and try to do it by accessing directly the date of the files in the '.git' objects folder. But it will be more difficult to do. – Philippe May 13 '21 at 12:24

1 Answers1

1

I was working in VSCode and staged all changes (using the GitLens extension).
Next I double clicked on a commit and this commit was checked out (no message or warning).

The previously staged changes are not shown anymore

That last part needs to be verified in command-line, outside of VSCode.

git status
git stash list

If not, as commented by Philippe, git fsck can somewhat help.

But check first what extension you are using: a double-click on a commit history should not switch to it directly, unless your VSCode+Git Lens also uses the Git Graph extension.
That extension includes issue 39: "On double click - Checkout branch", which seems close to what you have experienced.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I re-checked and it's the Git Graph extension and exactly your linked issue 39. – Lars May 13 '21 at 13:27
  • @Lars That would be the origin of your problem, then. If possible, don't use that extension for now. – VonC May 13 '21 at 19:30