gitignore logic for stignore v2

Feature
1

Hi there,

I just more or less finished my contribution by implementation the reflection of stignore patterns for nautilus file manager (https://github.com/syncthing/syncthing-gtk/pull/538), and realized that the logic of stignore files is very confusing.

As a developer I’m used to a hierarchical structure, and I do like the gitignore logic. The last applicable pattern wins.

In stignore, it seems to be mixed or reversed.

If I have a structure:

- Client Specific Documents
   - Client1
      - Data
      - Projects
   - Client2
   - Client3

My goal is to sync only the Client1 Folder but not the Data folder within this folder. The correct stignore content is(?):

/Client Specific Documents/Client1/Data
!/Client Specific Documents/Client1
/Client Specific Documents

Means: I need to write the deepest level ignore first, then the exclude of ignore on a parent level and then the ignore for all files on the highest level. If I reverse the order oder write the ignore of Data after the exclude pattern (!), it would sync the data against my intention. And if I write the /Client Specific Documents as first line, it would sync also Client2 + 3. This makes pattern way more difficult to understand as they need to be.

A gitignore pattern would be very simple and logically easier:

/Client Specific Documents -> first exclude main folder and all sub-items
!/Client Specific Documents/Client1 -> Include Client1
/Client Specific Documents/Client1/Data -> Exclude the data of Client1

stignore seems to reverse the logic and requires to go from the most deep tree level to the top. Instead from top to a deeper level. Anyone else the same opinion that “overview first” and then “deeper level” is normally the right approach :)? Was this maybe already discussed in the past?

1 Like
2
3

Thanks for the hint! The discussion goes far beyond a more intuitive ignore logic (eg choosing which ignores should apply that can be synced, thats a very complex approach).

1 Like