Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support nested .gitignore files in --pants-ignore-use-gitignore #19860

Open
stuhood opened this issue Sep 18, 2023 · 0 comments
Open

Support nested .gitignore files in --pants-ignore-use-gitignore #19860

stuhood opened this issue Sep 18, 2023 · 0 comments

Comments

@stuhood
Copy link
Member

stuhood commented Sep 18, 2023

After #5682 and #18649, the situation is that Pants uses the root and global .gitignore files when --pants-ignore-use-gitignore is enabled (as it is by default).

This ticket covers supporting non-root/global .gitignore files in child directories.


The implementation of --pants-ignore-use-gitignore initially used a naive recursive-upward parse of .gitignore files: this meant that for every file-ignore lookup, we would re-parse all parent .gitignore files. Consequently, that aspect was skipped in #9310.

Instead, in order to support nested .gitignore files efficiently while watching changes made to them, we would need to add recursive-upward memoization of .gitignore parsing. The memoization could either be accomplished by:

  1. creating a new Gitignore node, which recursively depended upwards on itself to parse parent Gitignore nodes.
  2. adding Gitignore information to the Scandir node, such that whenever we called Scandir on a directory, we also exposed and memoized a GitignoreStyleExcludes struct from the Node. Then, Scandir nodes would recursively depend on the parent Scandir node.

To reduce overhead (by creating fewer Nodes), I think that approach 2 would be cleaner. But if it ended up increasing complexity too much, then approach 1 would be fine as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants