Feature Request: Optionally Include Unstaged/Untracked Changes

[atxtechbro]

Description:

We are considering adding support for optionally including unstaged and untracked changes when running Siphon. This feature will allow users to extract the context of a repository, including not only the committed files but also the files that are yet to be committed or tracked by Git.

Purpose:

• The community has expressed interest in ensuring that incomplete changes (those that haven’t been staged or committed) can be captured by Siphon for testing or context purposes.
• This option will be disabled by default to avoid accidental inclusion of untracked/unstaged changes, but we want to gather feedback on how users would prefer this feature to be implemented.

Details:

• CLI Argument: We’ll add a flag like --include-unstaged or --include-untracked that users can pass when they want to include these types of changes.
• Documentation: We'll update all relevant documentation, including the CLI help (--help) and README to explain how this feature works.
• Next Release: This feature is planned for inclusion in the next release, but before finalizing the implementation, we want feedback on:
  • Preferred CLI flag syntax.
  • Whether this option should handle unstaged and untracked changes separately or as one unified flag.
  • Any potential edge cases to consider.

Request for Community Input:

1. How often do you find yourself wanting to include unstaged or untracked changes in an extraction?
2. Should these be handled as separate options (e.g., --include-unstaged and --include-untracked), or would you prefer a single flag that covers both cases?
3. Any other feedback or suggestions?

We encourage everyone to comment with their use cases, thoughts, and suggestions so we can build this feature in a way that benefits the community most!

Tasks:

• Implement CLI flags for including unstaged/untracked changes.
• Update CLI help (--help).
• Modify README with usage instructions.
• Ensure the feature is optional and well-documented.
• Thoroughly test the implementation with both small and large repositories.

---