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
git commit
fails, ultimately causing lost work
#565
Comments
Hmm, this looks like an issue with some permissions on your machine to me.
Do you know why this might happen? Why there are this permissions problem occur? To clarify: yes, lint-staged uses Did something change on the permissions since last week? |
Hmmm. The reason I'm suspicious about the permissions issue is because Windows users often have permissions issues with Git which aren't really issues. Usually it's because a file is open and Git can't modify it because there's a lock on it or something. The weird thing is that the |
I think we could do a better job in case a command has failed but it will increase the complexity greatly so I’d like to keep things simple until it’s proven to be an issue for many users. Please feel free to close if you can’t repro it for now. |
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. |
Feel free to propose a PR with such an option. |
if there are file changes on both working directory and staging area, sometimes, this issue will reproduce, in my case.
|
@guidetheorient can you please share your environment metadata? (e.g. operating system) |
I should mention that I do |
I have the exact same issue. It is difficult for me to reproduce it, as well. I am only guessing here, but it may have something to do with file watchers running at the same time with In particular, I am running I think that the |
Are you also on Windows? This seems to be a OS related problem but I’m not sure yet. I’ve been using this feature on several webpack-based projects with watchers running without any issues for months. Also there are lots of people using this version at the moment so it looks like there is something specific to the setup or os here. |
Yes, I am also on Windows (10, to be precise). And it happens randomly in my case, too. The only reason I mention file watchers and Thanks a lot for the quick reply! I really appreciate it. Please, tell me if there is anything else that you would like to know. |
Could you run an experiment and every time you commit a partially staged files to stop the watcher processes? If we could narrow down to the root cause it would definitely help with a possible solution. |
Yes, of course. I will do that and let you know if the problem persists. |
@FlorianWendelborn sorry for the late response. I'm on windows 10 home basic(version 1803), git version 2.14.2.windows.1, node v8.11.1 |
I'm seeing this issue on Windows as well, related to if a file is still open by another application and you try to run this code. Is there any reason this code doesn't just use git stash save "lint-staged-{uniqueidhere}" Why does it execute the following? // eslint-disable-next-line
async function gitStashSave(options) {
debug('Stashing files...')
// Save ref to the current index
indexTree = await writeTree(options)
// Add working copy changes to index
await execGit(['add', '.'], options)
// Save ref to the working copy index
workingCopyTree = await writeTree(options)
// Restore the current index
await execGit(['read-tree', indexTree], options)
// Remove all modifications
await execGit(['checkout-index', '-af'], options)
// await execGit(['clean', '-dfx'], options)
debug('Done stashing files!')
return [workingCopyTree, indexTree]
}
async function writeTree(options) {
return execGit(['write-tree'], options)
} |
There is a reason for that. It is required to support partially staged files. Feel free to experiment with stash since there is a good test coverage in place. |
Ideally if someone could add a failing test for Windows that would be a great help already. |
We've simply opted to just no longer use lint-staged for the time being as this "Stashing changes" feature has proven to be incredibly unsafe, especially since we're still waiting on PR #573 to be merged and published as well. If this issue persists, I'll see if I can set aside more time to help with this but that might take a few months. |
Experiencing this sporadically myself. Super scary. Thought it was related to having webpack watching or something, but then it happened while that wasn't running either, so... Shortened log from latest incident below. Just cut out a lot of the "error: unable to create file ... " errors, as there were quite many. Most of the files listed weren't even staged or changed.
|
i should also mention that it would happen in our case without watchers running as well. Just simply on the lint-staged pre-commit hook, and failing on a file which wasn't even open or modified: in our case README.md. Although the nature of the error message indicates to me that it is a file-lock issue with that file. The |
Is anyone here would be able to create a failing test case at least? It sounds like the issue is with git on Windows but I have no idea what it might be and I’m not a windows user. So please everyone don’t rely on me with fixing this and take over this issue. I need your contributions here. |
We have macOS and Linux users experiencing this issue. We're effectively removing lint-staged from our workflow, because this has now caused us to lose many hours of work twice. It's easily reproducible, as documented in #550, so the lack of acting is a bit worrying. |
@egeriis I'm as frustrated as you with this, but to be fair @okonet has reached out for assistance multiple times about this issue, and none of us have stepped up. I also see that in the issue you linked, he specifically asked you for more info, and you haven't answered or yet provided a repo with a minimal example. @okonet I'm sorry I haven't had the time to follow up on this. I was planning to at least try implementing the workaround mentioned earlier. I'll bump it to the top of my list after the next project deadline... |
@larskinn I wouldn’t go as far as to say I haven’t answered any of their questions, but I haven’t prioritized creating a repo to reproduce the issue, correct. I’ve thoroughly documented how to repro though. 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. |
🎉 This issue has been resolved in version 9.5.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This issue has been resolved in version 10.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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: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 throughgit fsck --unreachable
and inspect each blob (orgrep
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.The text was updated successfully, but these errors were encountered: