0

I did:

git add --all # success
git status # saw all my changes in staged area
git commit -am wip # failed because of some hooks (it was expected behavior)
# fixed the issue which causes the hooks to fail

then:

~ git add --all
fatal: Unable to create '/Users/stavalfi/projects/dancer/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

then:

rm /Users/stavalfi/projects/dancer/.git/index.lock
git add --all
git status

the last command showed me only the new files I added.

I lost all changes in all tracked files.

What to do?

Stav Alfi
  • 13,139
  • 23
  • 99
  • 171
  • Are you sure they were lost? From what I understood, your third command was commit amend, so maybe your changes in the last commit... – Just Shadow Feb 15 '21 at 13:40
  • In case they're lost, this answer might be helpful: https://stackoverflow.com/a/42861993/5935112 – Just Shadow Feb 15 '21 at 13:46
  • This doesn't help in your current situation, but I recommend *avoiding* `git commit -a`. (The `-m` option is fine, it's the `-a` option that you should avoid.) – torek Feb 15 '21 at 23:16
  • @torek If you are suggesting that, I will stop. Can you explain the reason? is it buggy? bad practice? hard to understand what it really does? – Stav Alfi Feb 15 '21 at 23:38
  • 1
    It's slightly hard to understand *and* it tends to interact badly with some pre-commit hooks. I'd be concerned in this case that this is how your files got mangled. It's not really your fault—probably, whoever wrote the pre-commit hook was unaware of the `-a` option, and how it works, and they put bugs in their hook that you ran into. But you'll avoid the bugs by avoiding the option! – torek Feb 15 '21 at 23:59
  • @torek In case you encounter the same question in the future, I'm using https://github.com/typicode/husky for generating the git-hooks. Also I'm using husky for couple of years and expect some minor bugs which the hooks are not activated, I never encounter such a strange bug. Thank! – Stav Alfi Feb 16 '21 at 18:37
  • 1
    It looks like Husky itself is just a framework. It includes an example / ¿default? pre-commit that runs `npm test`, which I think *should* be safe, but I'm not an npm expert. But it also allows you to add more hooks, and each author of each hook needs to be aware of the Git rules, so some third-party add-on might be the culprit here. – torek Feb 16 '21 at 21:20

1 Answers1

4

It certainly shouldn't have. By running git add --all, you asked git to:

Update the index not only where the working tree has a file matching <pathspec> but also where the index already has an entry. This adds, modifies, and removes index entries to match the working tree.

Unless the hook that ran as part of your checkout command did something to the working directory, the state of the index between running the two git add --alls should be the same. And the resulting commits should result in the same tree.

But if something did happen, you are in luck. git add adds the files as "blobs" to the object database. Since you did not commit that data, it is considered garbage and will eventually be garbage collected. But until then, you can recover it.

The easiest way to find these is to use a special purpose tool, git-recover which can find these unreferenced blobs for you.

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
  • i already tried git-recover. didn't work or maybe i used it wrongly. can you give the extact commands to help me out? – Stav Alfi Feb 15 '21 at 21:04