fsnotify is derived from code in the golang.org/x/exp package and it may be included in the standard library in the future. Therefore fsnotify carries the same LICENSE as Go. Contributors retain their copyright, so you need to fill out a short form before we can accept your contribution: Google Individual Contributor License Agreement.
Please indicate that you have signed the CLA in your pull request.
For smooth sailing, always use the original import path. Installing with go get
makes this easy.
go get -u github.com/fsnotify/fsnotify
)git checkout -b my-new-feature
)git commit -am 'Add some feature'
)Contribute upstream:
git remote add fork git@github.com:mycompany/repo.git
)git push fork my-new-feature
)This workflow is thoroughly explained by Katrina Owen.
fsnotify uses build tags to compile different code on Linux, BSD, macOS, and Windows.
Before doing a pull request, please do your best to test your changes on multiple platforms, and list which platforms you were able/unable to test on.
To aid in cross-platform testing there is a Vagrantfile for Linux and BSD.
src
folder.vagrant up
from the project folder. You can also setup just one box with vagrant up linux
or vagrant up bsd
(note: the BSD box doesn't support Windows hosts at this time, and NFS may prompt for your host OS password)vagrant ssh linux -c 'cd fsnotify/fsnotify; go test'
.Notice: fsnotify file system events won't trigger in shared folders. The tests get around this limitation by using the /tmp directory.
Right now there is no equivalent solution for Windows and macOS, but there are Windows VMs freely available from Microsoft.
Help maintaining fsnotify is welcome. To be a maintainer:
To keep master clean, the fsnotify project uses the "apply mail" workflow outlined in Nathaniel Talbott's post "Merge pull request" Considered Harmful. This requires installing hub.
All code changes should be internal pull requests.
Releases are tagged using Semantic Versioning.