gitignore logic for stignore v2

Hi there,

I just more or less finished my contribution by implementation the reflection of stignore patterns for nautilus file manager (, 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

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