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
Added files ignored by guard plugins #924
Comments
When we copy files, this will ignore the added file, which is not expect (when we have a task with sync files to other server) . so pls let us config to designed it should ignore or not |
I'm running into a similar issue due to the docker4mac/osxfs usage + my vim settings This is relatively easy to work around by monkey-patching the Guard::RSpec plugin in the guard file.
It would be a nice extension to make it more configurable based on events that guard receives so that a user can readily configure which events trigger plugin methods, rather than forcing users to modify editors (and other software) in order to work with this software. |
I think it could be a good idea to introduce a new plugin option, e.g. |
@rymai and @thibaudgg decided in #495 (comment) and #495 (comment) to drop support in several plugins for running on created/added files, in favor of avoiding redundant runs on save in editors like vim and Sublime configured for atomic save (e.g. guard/guard-minitest#98). This is usually a great tradeoff since a new file can generally be saved again to trigger a run.
Unfortunately this is fatal for users of the mutagen file sync tool. Our team uses mutagen to efficiently bi-directionally sync changes between our OSX Docker hosts and Docker containers for development where guard runs. In order to sync files atomically, when a file is modified on the host, mutagen moves a new copy of the file into place. The result is that listen detects every modification as a
:moved_to
or:added
event, and therefore many guard plugins never run on changes synced by mutagen.I'm posting this issue on the guard project because many guard plugins are affected.
I have confirmed that aliasing plugins'
run_on_modification
asrun_on_additions
(and removing any existing no-oprun_on_additions
method) resolves the problem.I want to make sure that we don't re-introduce the multiple runs per save issue previously reported. Has anything changed since #495 was filed in 2013 that would prevent multiple runs for a single save in editors configured for backup/atomic save, or would such aliases likely reintroduce the problem?
If I can determine how to effectively support allowing
added
files to trigger runs without the multiple runs problem for affected editors, then is this a change that you would be willing to accept? The project has been a little quiet, so I'd like to hear support from a maintainer before I sink time into this.Thanks!
The text was updated successfully, but these errors were encountered: