# Pijul Fork Mission
## Auto-complete intent tags for messages
The intent tags are used to categorize messages and make it easier for users to find relevant information. The auto-complete feature will provide instant keyword-based search results as the user types their message, supplied from the log of messages in the current repository. This will help users quickly find and use relevant tags without having to remember them all.
## Allow config default log order to be set to either ascending or descending
Currently, the default log order is set to ascending, which means that the oldest commits are shown first. Allowing users to set the default log order to either ascending or descending will give them more flexibility in how they view their commit history. This can be particularly useful for users who prefer to see the most recent commits first, as it can help them quickly identify recent changes and updates in the repository.
## Allow 'staging' of changes to be done in a more granular way
Currently, staging changes in Pijul is only done in spirit, via the `pijul record` command, which allows an opportunity to edit the record message and select which changes to include in it. However, this process can be improved by allowing users to stage changes in a more granular way, similar to how Git allows users to stage individual lines or hunks of changes. This would give users more control over which changes they want to include in a commit and make it easier to create more focused and meaningful commits. Implementing this feature would enhance the user experience and make Pijul more versatile for different workflows.
There are two levels to this feature. At one level is the simple ability to do what removing hunks does from the pijul record message editor, but without having to go through the process of editing the message. This would allow users to quickly stage or unstage specific changes without having to modify the commit message.
The second level of this feature would be to allow users to stage changes at an even more granular level, such as individual lines or hunks of changes. This would require a more complex implementation, but it would give users even more control over their commits and allow them to create more focused and meaningful commit messages. This level of staging would be particularly useful for users who want to create commits that are focused on specific changes or features, rather than including all changes in a single commit. This level is out of scope for the initial implementation, but it is something that could be considered for future development.
## Allow displaying more info, other ways, in the credit output
The `pijul credit` command currently displays a list of lines in the file and what record hash they were last changed in. Would be nice to have record message and/or author as well, and maybe even the date of the change.
The command could also provide a side-by-side view of the file with the credit information, similar to how Git's `blame` command works. This would allow users to see the changes in context and understand how they relate to the overall file history.
## Allow more lines of context to show, in the diff output
Currently, the `pijul diff` command shows a limited number of lines of context around the changes. Allowing users to specify how many lines of context they want to see would give them more flexibility in how they view the differences between commits. This can be particularly useful for users who want to see more of the surrounding code to better understand the changes being made. Implementing this feature would enhance the user experience and make it easier for users to review and understand changes in their codebase.
## Allow dir/file-scoped diff and record
Currently, the `pijul diff` and `pijul record` commands operate on the entire repository. Allowing users to specify a directory or file scope for these commands would give them more control over which changes they want to review or commit. This can be particularly useful for users who are working on large repositories with many files, as it allows them to focus on specific areas of the codebase without being overwhelmed by changes in other parts of the repository. Implementing this feature would enhance the user experience and make it easier for users to manage their commits and review changes in their codebase.
## Allow tracking merge records for potential unrecording (for feature composition forward and backward)
This seems like the easiest way to allow 'unrecording' after a `pijul apply --channel` command, which applies all the records in a channel. Wait... Does apply already track this? Where you'd just unrecord the records listed in the apply message? Or maybe apply doesn't actually make any new records. I need to research this more. I think apply just adds the records to the current channel, meaning there's no saved record of all the records that were part of the channel. If that's the case, then it would be useful to track merge records for potential unrecording, as it would allow users to easily undo the changes made by an `apply` command if needed. This would enhance the user experience and provide more flexibility in managing changes in the repository.

# Pijul Fork Mission
## Auto-complete intent tags for messages
The intent tags are used to categorize messages and make it easier for users to find relevant information. The auto-complete feature will provide instant keyword-based search results as the user types their message, supplied from the log of messages in the current repository. This will help users quickly find and use relevant tags without having to remember them all.
## Allow config default log order to be set to either ascending or descending
Currently, the default log order is set to ascending, which means that the oldest commits are shown first. Allowing users to set the default log order to either ascending or descending will give them more flexibility in how they view their commit history. This can be particularly useful for users who prefer to see the most recent commits first, as it can help them quickly identify recent changes and updates in the repository.
## Allow 'staging' of changes to be done in a more granular way
Currently, staging changes in Pijul is only done in spirit, via the `pijul record` command, which allows an opportunity to edit the record message and select which changes to include in it. However, this process can be improved by allowing users to stage changes in a more granular way, similar to how Git allows users to stage individual lines or hunks of changes. This would give users more control over which changes they want to include in a commit and make it easier to create more focused and meaningful commits. Implementing this feature would enhance the user experience and make Pijul more versatile for different workflows.
There are two levels to this feature. At one level is the simple ability to do what removing hunks does from the pijul record message editor, but without having to go through the process of editing the message. This would allow users to quickly stage or unstage specific changes without having to modify the commit message.
The second level of this feature would be to allow users to stage changes at an even more granular level, such as individual lines or hunks of changes. This would require a more complex implementation, but it would give users even more control over their commits and allow them to create more focused and meaningful commit messages. This level of staging would be particularly useful for users who want to create commits that are focused on specific changes or features, rather than including all changes in a single commit. This level is out of scope for the initial implementation, but it is something that could be considered for future development.
## Allow displaying more info, other ways, in the credit output
The `pijul credit` command currently displays a list of lines in the file and what record hash they were last changed in. Would be nice to have record message and/or author as well, and maybe even the date of the change.
The command could also provide a side-by-side view of the file with the credit information, similar to how Git's `blame` command works. This would allow users to see the changes in context and understand how they relate to the overall file history.
## Allow more lines of context to show, in the diff output
Currently, the `pijul diff` command shows a limited number of lines of context around the changes. Allowing users to specify how many lines of context they want to see would give them more flexibility in how they view the differences between commits. This can be particularly useful for users who want to see more of the surrounding code to better understand the changes being made. Implementing this feature would enhance the user experience and make it easier for users to review and understand changes in their codebase.
## Allow dir/file-scoped diff and record
Currently, the `pijul diff` and `pijul record` commands operate on the entire repository. Allowing users to specify a directory or file scope for these commands would give them more control over which changes they want to review or commit. This can be particularly useful for users who are working on large repositories with many files, as it allows them to focus on specific areas of the codebase without being overwhelmed by changes in other parts of the repository. Implementing this feature would enhance the user experience and make it easier for users to manage their commits and review changes in their codebase.
## Allow tracking merge records for potential unrecording (for feature composition forward and backward)
This seems like the easiest way to allow 'unrecording' after a `pijul apply --channel` command, which applies all the records in a channel. Wait... Does apply already track this? Where you'd just unrecord the records listed in the apply message? Or maybe apply doesn't actually make any new records. I need to research this more. I think apply just adds the records to the current channel, meaning there's no saved record of all the records that were part of the channel. If that's the case, then it would be useful to track merge records for potential unrecording, as it would allow users to easily undo the changes made by an `apply` command if needed. This would enhance the user experience and provide more flexibility in managing changes in the repository.