-
Notifications
You must be signed in to change notification settings - Fork 81
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
-i has confusing semantics #82
Comments
This is most probably an upstream issue. Ask on watchexec. |
I tried to replicate this with all combinations of macOS/Windows and cargo watch/watchexec. (Note that I tried it on Windows 10, I don't have an 8.1 machine around.) So, can you add |
Thanks for having a look @mattgreen :) |
Any update on this? :) |
@Boscop can you provide a |
As requested here: rust-lang/cargo#5169 (comment) I do not think it is watchexec issue as changes on file system are detected correctly. In my case .gitignore is observed by the
All the above cause the following infinite cyclic loop (when target_watch is not in gitignore):
Before the loop starts, it prints the following debug:
However, I managed to find the right combination for -i argument to stop the infinite restart loop. The following works but value for -i option is
|
Thank you, that should help! |
Thank you for attaching log output. This line doesn't look right:
There are two issues here:
I'll take a look. I have a backlog of bugs I need to move through and am evaluating a better design for watchexec currently anyway. |
Actually, this doesn't involve
That is a reasonable thing to expect, but it isn't currently implemented. |
I'll clarify this in readme and help message for cargo-watch. To help: I think I could automatically translate |
Maybe this crate is useful for this? |
Closing (reopen if it still occurs) |
This doesn't ignore the frontend folder's contents: Why doesn't the first one work though? (It works with other tools that have a similar purpose..) |
Yes, my bad, should still be open. See the last comment by matt green as to why this. |
Ignoring seems to be broken even for normal files in the root that are specified specifically by name. |
Can you provide examples of what you're trying and what platform this is on?
…On Tue, 23 Oct 2018, 09:40 Joe Taber, ***@***.***> wrote:
Ignoring seems to be broken even for normal files in the root that are
specified specifically by name.
Would it be possible to rely directly on ignore
<https://docs.rs/ignore/0.4.4/ignore/overrides/struct.Override.html#method.matched>
of ripgrep to do the ignore logic instead of doing it in-house?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#82 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJgi8Vj3xwtVDtFdXDkl4wPINZqn6Epks5uni00gaJpZM4PxO2p>
.
|
Absolutely. Sorry for not providing more details at first. Repro:
Aaaand I just realized my case is probably related to the extra files that vim creates when saving. It also occurs when my app is running, which happens to use a sqlite db.... which also creates auxiliary files. And after checking for and eliminating both of these cases cargo-watch is behaving as expected again. I should have used --debug first. Sorry! |
I think a pull request covered the vim files recently, but just in case can you give their names/extensions? Also for the sqlite db ones, I think there would be benefit to adding those by default |
For sqlite, in my case it was Rerunning the vim test, it looks like vim was creating My fix for vim is to EDIT: |
The sqlite ignores are now in 7.0.7. |
To clarify again, this issue is not technically about a code bug, but about the misinterpretation of what |
Closing in favour of upstream issue: watchexec/watchexec#188. |
Cargo watch doesn't ignore
app.db
even though I have it in.gitignore
and even when I pass it to the command like:cargo watch -i app.db -x "run -p mybin"
(I'm running this in a workspace where mybin is the binary I want to run.)
My .gitignore looks like this:
I'm on Windows 8.1.
When my exe writes to app.db, it triggers cargo watch to restart the exe, why?
The text was updated successfully, but these errors were encountered: