Use git stashes in git workflow for better performance

[iiroj]

Revival of #663 in the beta branch.

---

• Fixes Issue with partially staged files #737
• Fixes Killing the lint script causes unstaged changes to be lost #583
• Fixes staging changes breaks git lfs #586
• Fixes lint-staged doesn't restore unstaged changed when it fails #550
• Fixes [Question] Why not use git stash save --keep-index #602
• Fixes git commit fails, ultimately causing lost work #565
• Fixes Deleted files restored after committing with no files matching lint-staged config #561
• Fixes Check if updateStash step is needed #528
• Fixes 100% test coverage #259
• Fixes IntelliJ and auto-fix code leaving staged and not staged files #151

[codecov]

Codecov Report

Merging #724 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #724   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          13     13           
  Lines         429    429           
  Branches       97     97           
=====================================
  Hits          429    429

---

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 82bee06...f9e128d. Read the comment docs.

[fringd]

hey what's the latest with excellent PR?

[okonet]

@iiroj I'm ready to merge if you think it's complete. Just let me know if I should do the release. Also, did you add the BREAKING CHANGE marker?

[iiroj]

@okonet since you experienced the bug with deleted files getting resurrected, maybe double-check that just in case after bbfae43. Theres a breaking change comment in 4fe53ef

[okonet]

@iiroj thanks for the update. I'm wondering if this is somehow related to the behavior I saw with #750? WYT?

[iiroj]

@okonet Yeah, I made a logic error in the improved error handling where the backup stash was dropped ("cleaned up") even though there were errors in the previous step. I'll improve it some, but since it's the holidays I'm not sure when. Probably push a commit now and then cleanup in about a week.

[iiroj]

What do you think, @okonet? There haven't been any new bug reports...

[okonet]

I'd merge asap! We can iterate on a bigger user base. That should be a community effort and it should not stop us from shipping.

[iiroj]

I'm in a good position right now in the sense that I have time to react to possible bugs after merging, so let's do it!

[iiroj]

@okonet I'm not sure what squashing will do to the multiple breaking change comments, though. Should this just be merged without squashing?

[okonet]

🚀

[okonet]

@iiroj yes, we should do a normal merge in this case since all commits are following the convention and the version will be calculated correctly.

[okonet]

Feel free to merge (do not squash, please) when the build has passed.

[okonet]

🎉 This PR is included in version 10.0.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[taion]

I might be missing something, but I think 5208399 and 083b8e7 interact in an odd way.

I have a repo that includes a GraphQL schema. I want this schema to get regenerated on every commit to match the code.

Previously, I had a command like git add data/schema.graphql that would add my changes to the GraphQL schema.

Now, however, this gives me the warning added above.

I could switch to using a function here to add only the one file, but that would force me to opt out of using package.json to configure lint-staged, which I'd rather not do if I can avoid it.

[iiroj]

@taion do you mean your lint-staged task automatically edits other files, and now they don’t get added? This might be so, because we only pass the original list of staged files to git add.

Can you open a new issue so we can discuss there?

[okonet]

I think we still can allow git add . for such cases.

[taion]

Yup, I described it in more detail in #770.