You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was browsing through the README and wondering if there would be a way in the yml file to specify the working directory snag should watch in case I wanted to keep the .snag.yml defined somewhere else but specify either a particular subfolder I wanted to watch instead of exclude all the rest. Also in case it was relative (ie: ../directory) there woudn't be a way to do it via ignore.
Perhaps this is something I could pass in to the cli itself? path to the .snag file (and assume current directory as working one instead)?
I think it'd be cool to document somewhere all the options possible for the yml and the cli also as just simple "samples" don't cut it when you're looking for more advanced usecases?
The text was updated successfully, but these errors were encountered:
This may go hand in hand with the idea I had about running commands off the snag command without the need to have a .snag.yml file. I found myself wanting to run one or two commands without having to specify the file.
I think being able to specify the watch directory in the snag file would add a great deal of flexibility. I would like to see how we can approach this in a intuitive way.
I was browsing through the README and wondering if there would be a way in the yml file to specify the working directory snag should watch in case I wanted to keep the
.snag.yml
defined somewhere else but specify either a particular subfolder I wanted to watch instead of exclude all the rest. Also in case it was relative (ie:../directory
) there woudn't be a way to do it via ignore.Perhaps this is something I could pass in to the cli itself? path to the .snag file (and assume current directory as working one instead)?
I think it'd be cool to document somewhere all the options possible for the yml and the cli also as just simple "samples" don't cut it when you're looking for more advanced usecases?
The text was updated successfully, but these errors were encountered: