You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be helpful to allow users to configure gitingest behavior via a configuration file. This file could be located in the user’s home directory as ~/.gitingest or within the repository itself (e.g., .gitingest in the root).
The configuration could include:
Exclude patterns: To specify files or directories to ignore.
Custom prompts: Predefined instructions or prompts to prepend to gitingest output through user defined command-line flags.
A proposed format could be TOML or something similar for simplicity and readability.
Example:
[EXCLUDE]
patterns = ["*/tests", "*.csv"]
[PROMPTS]
refactor = "This file contains my entire codebase. Please review the overall structure and suggest any improvements or refactoring opportunities, focusing on maintainability and scalability."docs = "This file contains undocumented or partially documented functions and modules. Please identify areas where documentation is missing and suggest detailed descriptions or examples to improve clarity and usability using the numpy docstring format”
This feature would provide users with centralized and/or project-specific control over how gitingest operates, making it more flexible and user-friendly.
The text was updated successfully, but these errors were encountered:
I gave a though about this and I believe a .gitignore at the Reposity level would be a great way to tie ingestion settings to a specific work folder, and would ultimately make for a stable/shareable tooling for people using gitingest in their development process
In the long term a global config can also help (overwriten by local config when present)
It would be helpful to allow users to configure
gitingest
behavior via a configuration file. This file could be located in the user’s home directory as~/.gitingest
or within the repository itself (e.g.,.gitingest
in the root).The configuration could include:
gitingest
output through user defined command-line flags.A proposed format could be TOML or something similar for simplicity and readability.
Example:
This feature would provide users with centralized and/or project-specific control over how
gitingest
operates, making it more flexible and user-friendly.The text was updated successfully, but these errors were encountered: