Ah, ok, that makes sense. However it also results in the usual chicken and egg problem of not having the ignores available until after the folder has synced. I guess this is fine in your case if the ignores are always symmetrical. Regardless, it sounds like imsodins suggestion would be helpful.
1 Like
Just set up a new laptop; synced my files from my NAS; made sure everything was sync’ed correctly, all looks good. A week later, I notice there’s some weirdness where files that are in my ignore list aren’t being ignored… guess what I forgot to enable AGAIN? T_T
For everyone in this thread, who ‘forget’ to add the .stignore file on re-configuration and reconnect: Do sync this .stignore manually! Best to copy/rename it to stignore (remove the dot) so you can see it.
best idea, I’m always having a stignore.zip in the folder root as a reminder and apply it on all nodes manually.
I find these discussions about wanting to automate something just because you are forgetful yourself, a bit excessive.
The #include function alone makes things easier to be able to transmit the ignores via the peers that are also to be transmitted. Sure, a standard entry with e.g. “#include .stglobalignore” would be helpful in order to at least have a cross-peer design. Further entries with “#include .something” are also possible.
Nevertheless, a few tools can also be used to build a script that copies a basic stignore from a central directory to wherever it is wanted, at least within one’s own reach, whether locally or externally. And then circulating a .stglobalignore for each peer, if necessary individually, shouldn’t be not so difficult anymore.
What I mean by that, dealing with such elements is basically a conscious process that also entails responsibility, as you have to decide separately for each peer which profile should ultimately be considered ignore patterns.
1 Like