Fix untracked file handling

[iiroj]

This PR adds missing error handling to the untracked files restoration, and uses the same diff arguments as for the unstaged diff.

These omissions when combined possibly lead to new untracked files getting lost when running lint-staged. The test didn't detect this because one reason might be the missing --binary flag.

The test coverage dropped significantly because now when the backup stash is missing, runAll fails earlier. Not sure how to test the last error handler at this point.

Fixes #779

[codecov]

Codecov Report

Merging #780 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #780   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          13     13           
  Lines         449    480   +31     
  Branches      104    107    +3     
=====================================
+ Hits          449    480   +31

Impacted Files	Coverage Δ
lib/runAll.js	100% <100%> (ø)	⬆️
lib/gitWorkflow.js	100% <100%> (ø)	⬆️
lib/file.js	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0f2a1c0...b9d5939. Read the comment docs.

[iiroj]

@okonet if you're fine with these changes, please leave an approving review so that the merge button gets enabled for me.

[okonet]

🎉 This PR is included in version 10.0.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[millette]

@okonet Thanks for the quick turnaround.

Could you also run the following, which I think will make life easier, just in case:

npm deprecate lint-staged@10.0.2 "Broken, do not use"

[okonet]

@millette you should thank @iiroj since he was working on that.

npm deprecate lint-staged@10.0.2 "Broken, do not use"

Pretty much every previous version should be deprecated then, no? I don't see any reason to deprecate previous version since the fix is the patch release and should be automatically resolved by any modern bundlers.

[millette]

Thank you @iiroj

@okonet Well, the problem that deletes uncommited files is rather serious. I don't know to which versions it applies, hopefully only 10.0.2 but it's the sort of example given on https://docs.npmjs.com/cli/deprecate.

Semver takes care of this, sure. But a warning would be appreciated, and that's what npm deprecate provides.

[iiroj]

@millette we would probably have to deprecate versions 10.0.0, 10.0.1, and 10.0.2 because this bug was introduced in the breaking changes.

Luckily the files are not, and are recoverable from the depths of git (see the related issue).

[okonet]

V9 also had “serious” bugs that’s why v10 was released. I don’t think it’s worth the maintenance time to go through and deprecate all of those.