New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deleted files restored after committing with no files matching lint-staged config #561
Comments
I was just testing lint-staged as an alternative to the shell script I've been using for the same purpose. I noticed the same thing: a tracked file which has been deleted from the work tree but whose deletion has not been staged get undeleted as part of lint-staged's operation. Maintainers, see my script at https://stackoverflow.com/a/26685296/496046 for how I worked around this issue. It's pretty basic -- I just took a list of these files and then deleted them again when finished. |
I tested a little further. In all four of these cases: (
The file should be deleted when lint-staged is done, but it exists in the work tree again. |
🎉 This issue has been resolved in version 9.5.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This is fixed for the Here's a tarball of a repo in a state where files are in all four of the above statuses, plus one staged file which lint-staged takes into account. Test repo with various things staged/deleted If you extract this and cd into it, run
If you run
The files fileRD_renamed and fileAD should not be present in the work tree at this point, but are. You then need to run Here's a ttyrec session of me setting this repo up from scratch and testing it. I make a couple of mistakes in my ttyrec recording (play with |
🎉 This issue has been resolved in version 10.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
I updated to 10.0.1 and this is still not fixed for the AD and RD cases. I see exactly the same results as posted in my previous message in this thread. Here's a new git repo tarball with lint-staged updated:
I then need to run |
Thanks @tremby. Let me open this ticket again and see. EDIT1: This seems to be an issue in the calculation of the unstaged diff: diff --git b/fileMD a/fileMD
deleted file mode 100644
index 031943e..0000000
--- b/fileMD
+++ /dev/null
@@ -1,2 +0,0 @@
-fileMD
-new content
diff --git b/file_D a/file_D
deleted file mode 100644
index c97750d..0000000
--- b/file_D
+++ /dev/null
@@ -1 +0,0 @@
-file_D EDIT2: This is the backup stash, that should include the original state. It seems to miss the AD and RD cases: new file mode 100644
index 0000000..fa49b07
--- /dev/null
+++ b/fileAD
@@ -0,0 +1 @@
+new file
diff --git a/fileMD b/fileMD
deleted file mode 100644
index 3c085e3..0000000
--- a/fileMD
+++ /dev/null
@@ -1 +0,0 @@
-fileMD
diff --git a/fileRD b/fileRD_renamed
similarity index 100%
rename from fileRD
rename to fileRD_renamed
diff --git a/file_D b/file_D
deleted file mode 100644
index c97750d..0000000
--- a/file_D
+++ /dev/null
@@ -1 +0,0 @@
-file_D
diff --git a/test.js b/test.js
new file mode 100644
index 0000000..4636d04
--- /dev/null
+++ b/test.js
@@ -0,0 +1,3 @@ EDIT3: This issue seems to come from git stash save --include-untracked
git stash pop |
Maybe this would help with the deleted files reappearing: ❯ git ls-files --deleted
fileAD
fileMD
fileRD_renamed
file_D
❯ npx lint-staged
✔ Preparing...
✔ Running tasks...
✔ Applying modifications...
✔ Cleaning up...
❯ git ls-files --deleted
fileMD
file_D Save the first list and delete them after running? |
@iiroj I dropped some comments over on that PR. Works for me! Thanks! |
🎉 This issue has been resolved in version 10.0.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
I have several edits right now and a few files that were deleted. I'm now in the process of committing my changes in smaller chunks for a sensible git history, and I noticed the files that had been deleted kept appearing in my repo again (not for every commit, just some). Turns out, when I don't stage the deleted files and none of the files being committed match the
lint-staged
config, they seem to reappear for some reason. If I create a new file or modify an existing file that matches, everything runs as expected. Note that this seems to apply to all deleted files, unrelated to whether they match thelint-staged
config.I suspect this might be related to #75 and/or #387 (#75 is a feature that has brought so much joy to my heart ❤️ - thank you for all your great work!)
Update: I tried changing my
lint-staged
config to target all files from root, includingpackage.json
, assuming it would fix the issue, but it prevailed. I added an additional debug log below. It is almost identical, it seems to process thepackage.json
file this time as expected, but the error at the end seems to be the same.Relevant parts of my
package.json
On the second run I replaced the
src
inlint-staged
with.
resulting in thisSteps to reproduce
src
file, so I edited mypackage.json
as an example)git status
looked like this➜ git status On branch develop Changes to be committed: modified: package.json Changes not staged for commit: deleted: .eslintrc deleted: src/styles/Breakpoints.ts deleted: src/styles/Theme.ts
git status
claims to have a clean working tree, but the files should still be deleted.Debug Logs
expand to view debug log when only targeting `./src`
expand to view debug log when targeting all files in `./`
Environment
yarn
: v1.12.3lint-staged
: v8.1.0husky
: v1.1.3The text was updated successfully, but these errors were encountered: