`git commit` fails, ultimately causing lost work

This seems like it might be related to #550, #561, possibly #387, possibly #75… I’m really not sure, but just want to share where my investigation has led me.

This exact issue has happened twice to me, and while I’m not sure what the cause of it is, we reasoned it was related to husky so uninstalled it. Turns out, husky just sets up pre-commit hooks for us which we define, and the only one we’re using is: lint-staged I’m on a Windows, using MINGW64 git version 2.19.1.windows.1, Node v8.12.0. Here is the flow of events, including the error:

PPirault@Dev38 MINGW64 ~/Desktop/proj (feature/transfers-description)
$ git status
On branch feature/transfers-description
Your branch is up to date with 'origin/feature/transfers-description'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   app/components/account-selector/account-selector.spec.js
        modified:   app/components/checkbox/checkbox.spec.js
        new file:   app/components/input-field/input-field.spec.js
        modified:   app/components/selector/select.js
        renamed:    app/components/transfers-screen/transfers-screen.spec.js -> app/components/transfers-form/transfers-form.spec.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   app/components/checkbox/checkbox.spec.js
        modified:   app/components/input-field/input-field.js
        modified:   app/components/transfers-screen/transfers-screen.js
        modified:   bin/scaffold-component-test.js


PPirault@Dev38 MINGW64 ~/Desktop/proj (feature/transfers-description)
$ git commit
husky > pre-commit (node v8.12.0)
Stashing changes... [started]
Stashing changes... [failed]
→ Error: Command failed: git checkout-index -af
error: unable to create file README.md: Permission denied


Error: Command failed: git checkout-index -af
error: unable to create file README.md: Permission denied


husky > pre-commit hook failed (add --no-verify to bypass)

PPirault@Dev38 MINGW64 ~/Desktop/proj (feature/transfers-description)
$ git status
On branch feature/transfers-description
Your branch is up to date with 'origin/feature/transfers-description'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   app/components/account-selector/account-selector.spec.js
        modified:   app/components/checkbox/checkbox.spec.js
        new file:   app/components/input-field/input-field.spec.js
        modified:   app/components/selector/select.js
        renamed:    app/components/transfers-screen/transfers-screen.spec.js -> app/components/transfers-form/transfers-form.spec.js

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    README.md

As you can see, there is a git checkout-index -af (happening under lint-staged’s hood?), which is clobbering the unstaged changes. At that point, the only way (that I know of) to recover the lost work is to comb through git fsck --unreachable and inspect each blob (or grep through them if I can remember a change) to find the changes. This happened intermittently and we have been using lint-staged in our project without issues for the last 2 months, with an average of 5 git commits per weekday. The two occurrences happened only within the last week. Please correct me if this is not lint-staged’s issue.

[larskinn]

My team is experiencing the same issue from time to time, also on Windows, using Git for Windows. Haven’t found a way to reproduce it.

For us, it would be great if this stash-then-lint-then-checkout mechanism (and thus support for linting staged parts of a file only) could be disabled in configuration. No matter if the fault is in lint-staged or Git for Windows, risking loss of work seems like a high price to pay for the convenience of not having to fix linting errors in the entire file.

[okonet]

I’m more annoyed at leaving such a glarring and major issue in a project of this scale in what’s supposedly a stable release. That’s my main critique and in my opinion inexcusable.

I’m also annoyed by the assumption that I’m going to jump on the issue that doesn’t even have a reproducible case and fix it for you. It’s not my full time job and I’m not getting paid for any work I did in this repo.

Instead of telling me you’re removing it from your company’s workflow (I couldn’t care less tbh) you could ask the company to allocate time and developers to fix the issue. But I guess open source reached the point there i have to explain how it works.

I’m blocking this conversation since none of the recent comments moved us closer to the resolution nor the root cause.

If someone has something valuable to add, create a PR with a fix or a failing test case.