Execution Flow of should_ignore

This document explains how the .gitignore rules are processed by the Runex ignore logic code when should_ignore is called. We’ll walk through an example call to demonstrate the order of function invocations and internal logic.

Example Scenario

Assume we have a project with the following simple .gitignore rule stored in a file (located at the root):

*.log

And we want to determine if the file src/app.log should be ignored.

Step-by-Step Execution Flow

1. Instantiating the Scanner and Loading Patterns

2. Calling should_ignore

3. Normalizing the Path

4. Iterating Over Collected Patterns

5. Inside GitIgnorePattern.hits()

6. Handling Negation and Final Decision

7. Returning the Outcome


Summary of the Function Call Order

  1. GitIgnoreScanner Initialization & Loading:
    • GitIgnoreScanner(root_dir)
    • GitIgnoreScanner.load_patterns()
      • Internally creates multiple GitIgnorePattern instances via GitIgnorePattern.__init__()
      • Calls GitIgnorePattern.compile_regex() for patterns with slashes
  2. Checking a Specific Path:
    • GitIgnoreScanner.should_ignore("src/app.log", is_dir=False)
      • Normalizes the path
      • Iterates over each pattern:
        • Adjusts the path based on pattern.source_dir
        • Calls GitIgnorePattern.hits(match_path, is_dir)
          • If no slash: calls wildmatch() on the basename
          • If slash present: uses compiled regex for matching
      • Applies negation rules as needed
      • Returns the final decision

This structured flow ensures that each pattern is applied in the correct context, ultimately determining whether the file should be ignored. By following the above steps, the code effectively mimics Git’s own behavior for handling .gitignore files.


This document should serve as a detailed guide to help anyone understand how the ignore logic processes a file path step by step.