Enhancement: Decouple .graphifyignore discovery from .git boundaries

[Deep-Axe]

The current _load_graphifyignore implementation relies exclusively on the presence of a .git/ directory to stop its upward search for ignore rules.

The Problem

Currently, graphify assumes that every project is managed by Git. If a user runs the tool on a directory that is not a Git repository (e.g., a simple folder of research papers or a project using Mercurial/SVN), the logic will:

1. Continue climbing the directory tree past the intended project folder.

2. Potentially reach the user's home directory or the filesystem root.

3. Accidentally pick up and apply .graphifyignore rules from unrelated projects found higher up in the hierarchy.

This makes the tool less predictable when used outside of a strictly Git-centric workflow.

[Deep-Axe]

Thanks for the quick response and for adding the additional VCS markers and the home directory guard! That prevents the most extreme "drive-root" leakage.

However, I’d like to request that we reopen this to consider a more "hermetic" discovery strategy. While the home directory guard is a great safety net, it doesn't solve the Project-to-Project leakage problem.

The Remaining Failure Mode

Imagine a developer's workspace structure:

/work/
  ├── .graphifyignore  (generic rules for work)
  ├── project-alpha/   (No VCS, standalone)
  └── project-beta/    (No VCS, standalone)

If I run graphify . inside project-alpha, the current logic will still climb to /work/ and apply those ignore rules. This is counter-intuitive; as a user, when I point a tool at a specific folder, I expect that folder to be the "Source of Truth" unless the folder is explicitly part of a larger, recognized Unit (like a Git repository).

[safishamsi]

Fixed in 8a6306f (v6 branch). The upward walk now stops at the nearest VCS root (.git, .hg, .svn, etc.) — it never crosses into a different repository. Without a VCS root, the walk is capped at the home directory as a safety limit. Let me know if you test this edge case on your end and still face a problem

[Deep-Axe]

Thanks for the update and for expanding the VCS markers! However, the implementation in 8a6306f, I still see two issues:
Check out #646 for fixes:

• Pattern Priority is Reversed:
  In the current implementation, the loop climbs upward and appends patterns to the list as it goes:

  1. Read scan_root/.graphifyignore -> append to list.
  2. Read parent/.graphifyignore -> append to list.
  3. Read repo_root/.graphifyignore -> append to list.

  Because _is_path_ignored (and Git itself) uses "last-match-wins" semantics, this means the global repository rules will override local subdirectory rules. This is the opposite of expected behavior. Local rules must always be the "last" in the list so they take precedence over parent rules.

• Persistent Project-to-Project Leakage
  The current == home guard prevents scanning the whole disk, but it doesn't solve the leakage between projects in a shared workspace.
  Example: If I have ~/work/.graphifyignore and I run a scan in ~/work/standalone-project/ (which has no VCS), the tool will still climb to ~/work/ and apply those rules.
  Solution: Use the explicit scan root as the ceiling for non-VCS projects. If I run graphify /path/a, the tool shouldn't care what is in /path/, because as a user, I've defined my "Project" as the folder I pointed the tool at.

• line.strip() breaks Git-compliant whitespace
  The use of line.strip() at line 742 (in your latest commit) prevents the ability to match files with trailing spaces. Per the gitignore spec, trailing spaces are ignored unless escaped (e.g., vendor\ ). A simple strip() silently destroys this distinction, which is why a character-walk is required for spec-compliance.

[safishamsi]

Updated in 7f336ac with proper gitignore semantics addressing all points raised:

• Pattern order: outer-first collection so inner rules win via last-match-wins (ceiling → scan root, not upward append)
• Non-VCS hermetic: without a VCS root, scan is hermetic to the scan root — no parent leakage across sibling projects
• Trailing spaces: replaced line.strip() with _parse_gitignore_line() that uses rstrip('\n\r') + regex to strip only unescaped trailing spaces per gitignore spec
• Anchored patterns: leading-/ patterns now only evaluate against paths relative to their anchor dir, never the scan root

[Deep-Axe]

Your latest push doesn't actually do anything you've claimed it does.

• Pattern order: outer-first collection so inner rules win via last-match-wins (ceiling -> scan root, not upward append)

are you sure? I’d encourage you to read the code you pushed, it does the exact opposite. you are returning True on the first match while iterating from the ceiling down, global rules will now always override local ones, the core issue of the negation logic is unaddressed as well