Allowing to sync the .stignore file - any caveats?

After reading this thread and this comment, I’ve been thinking if a built-in global and local .stignore system would be a good idea, mimicking your setup. My idea is that every folder has a tab for “global ignores” and “local ignores” in the folder settings (under the already existing “Ignore Patterns” tab).

The global ignore rules would be applied to all devices within in the cluster, and would obviously have to be the first file pulled before all others.

The local ignore rules would be used to add rules that aren’t needed on other devices, or to be used to overwrite a rule in the global ignores list.

I’m initially thinking this would make managing ignores a bit easier, however I’m not sure if there’s enough use-case scenarios for it to be worth it, and also it might be too complicated.

1 Like

Yes, that sounds very cool. It would definitely allow for more personalised configuration. My solution is really just a quick, brute-force workaround :grimacing:.

Awesome, then we’re at least two who would use it! The question still stands if there’s a wide enough use-case for it. However, I haven’t really developed in Go, so I wouldn’t know where/how to start :sweat_smile:

1 Like

You can already achieve that by using include directive.

That’s true, however the current implementation does not allow including a file when the folder is added to a device. Adding for example #include .globalstignore to the rules when initially adding a folder will just throw an error, as the file doesn’t exist locally yet, which makes sense.

However I think it would be much better if Syncthing instead would pull the file(s) specified in the include(s) (if they exist in the cluster), apply those rules, and then begin pulling all other files.

The error thrown is this one

2020-08-02 19:13:19 Error on folder "Test" (94clu-ucu8j): loading ignores: failed to load include file .globalstignore: open \\?\[folder path]\.globalstignore: Det går inte att hitta filen.
1 Like

One solution could be a flag for optional includes (missing is not an error) combined with default ignore patterns (we want those anyhow).

Chicken-and-egg problem remains, but that’s the case with any synced-ignores setup…