1

What is behavior of git reset, specifically git reset --hard, while tree has no commits yet? (Just after git init). It just deletes everything?

Messed it up, while editing .gitignore. I tried to apply new changes to .gitignore, before making first commit. So, to ignore some new files, I had to clean index, and then make git add . again. I guess, plain git reset whouldn't do the mess, but I used git reset --hard, due to my geniusness.

Now, the project folder contains only .git folder with contents, and also the whole folder structure of a project, but without any files. Why?

Can I recover the files? What are my options in this case?

UPD

@kowsky pointed me in right direction - in this answer they explain how to recover files, that are temporarily stored in .git/objects (dangling blobs), like in my case (particularly, using this tool). I recovered everything, thank you!

Kostya
  • 33
  • 1
  • 7
  • If you did not commit those changes then those files are pretty much lost and not recoverable. You can, pretty much, always recover data that has been commited but you didn't in this case so I'd say it's not possible. – Mattia Righetti Apr 11 '18 at 11:01
  • `git status` provides you the correct command to unstage a file (it's `git reset HEAD `; notice that `--hard` is not included). `git reset --hard` makes the index and the working tree identical with the commit you pass it as argument. Since you don't have any commit yet, your repo is empty and the working tree has been synced to that. Your files are gone. – axiac Apr 11 '18 at 11:01
  • You should make that an answer. – Steve Bennett Apr 11 '18 at 11:04

2 Answers2

1

What is behavior of git reset, specifically git reset --hard, while tree has no commits yet?

If you add files and then use git reset --hard, your files will be deleted. Untracked files won't be touched.

Can I recover the files?

If you never added or commited the files, git does not know anything about them and won't be able to recover them. All files that were added, however, can be recovered. Here and here are answers on how to recover them.

kowsky
  • 12,647
  • 2
  • 28
  • 41
  • I used `git add .`. Did't make any commit, as I said. "Why did you clean the index" - I cleaned the index after updating gitignore, to apply changes. – Kostya Apr 11 '18 at 11:11
  • "What files did you create in your directories?" - just simple text files. Why does it matter? – Kostya Apr 11 '18 at 11:13
  • It does matter because I want to understand what is going on as good as possible. I edited my answer and added a link to an answer on *Recover once staged but not committed files?*. – kowsky Apr 11 '18 at 11:21
  • Oh yeah, now after this link I see why you asked about type of files. It was a python project, so there were plain text files + virtualenv folder (with some binaries) + sqlite database. But text files is everything i need. – Kostya Apr 11 '18 at 11:28
  • Answers to [this question](https://stackoverflow.com/questions/11094968/in-git-how-can-i-recover-a-staged-file-that-was-reverted-prior-to-committing) might actually be more helpful. – kowsky Apr 11 '18 at 11:29
  • Ok, thanks! Going to dig into this. I have some objects in `.git/objects` folder(20 MB), and if i am able to recover several files, I would be more than satisfied. – Kostya Apr 11 '18 at 11:37
  • I did recover all my files with the last link. Thank you, @kowsky, you saved my day! – Kostya Apr 11 '18 at 12:36
0

Let's clear this up.

You initialised your git local repository by running git init, this indeed creates the .git folder where all the git tools and objects would be stored.

When you make changes to a brand new, empty folder, those files are going to be untracked and by adding them with the git add . command what you did is copying those changes (everyone since you put the . in front of the command) from your working directory to the staging area. At this point your working directory and your staging area does contain the same files.

enter image description here

You did not commit those changes, so when you run git reset --hard HEAD you are basically saying "Make everything (staging area, working area, committed area) as the commit HEAD is pointing to, which in this case is none, indeed what this does in this case is delete everything.

Check this answer to see if you can get those files back.

To avoid this kind of deletion next time I would suggest to use either git reset --soft or git reset which is the abbreviation of git reset --mixed

This will probably explain things deeper.

Mattia Righetti
  • 1,265
  • 1
  • 18
  • 31