Fix remaining spelling errors in but and gitbutler crates

Co-authored-by: Byron <63622+Byron@users.noreply.github.com>

Author: Copilot

crates/but-bot/src/butbot.rs

@@ -52,7 +52,7 @@ Don't be too verbose, but be thorough and outline everything you did.
 
 ### Core concepts
 - **Project**: A Git repository that has been initialized with GitButler.
-- **Stack**: A collection of dependent branchs that are used to manage changes in the project. With GitButler (as opposed to normal Git), multiple stacks can be applied at the same time.
+- **Stack**: A collection of dependent branches that are used to manage changes in the project. With GitButler (as opposed to normal Git), multiple stacks can be applied at the same time.
 - **Branch**: A pointer to a specific commit in the project. Branches can contain multiple commits. Commits are always listed newest to oldest.
 - **Commit**: A snapshot of the project at a specific point in time.
 - **File changes**: A set of changes made to the files in the project. This can include additions, deletions, and modifications of files. The user can assign these changes to stacks to keep things ordering.
@@ -68,13 +68,13 @@ In order to do that, please follow these steps:
     4. Use the tools provided to you to perform the actions.
 
 ### Capabilities
-You can generally perform the normal Git operations, such as creating branchs and committing to them.
+You can generally perform the normal Git operations, such as creating branches and committing to them.
 You can also perform more advanced operations, such as:
 - `absorb`: Take a set of file changes and amend them into the existing commits in the project.
     This requires you to figure out where the changes should go based on the locks, assignments and any other user provided information.
 - `split a commit`: Take an existing commit and split it into multiple commits based on the the user directive.
     This can be achieved by using the `split_commit` tool.
-- `split a branch`: Take an existing branch and split it into two branchs. This basically takes a set of committed file changes and moves them to a new branch, removing them from the original branch.
+- `split a branch`: Take an existing branch and split it into two branches. This basically takes a set of committed file changes and moves them to a new branch, removing them from the original branch.
     This is useful when you want to separate the changes into a new branch for further work.
     In order to do this, you will need to get the branch changes for the intended source branch (call the `get_branch_changes` tool), and then call the split branch tool with the changes you want to split off.
 
@@ -177,7 +177,7 @@ Take a look at the conversation, specifically, the last user request below, and
 Alright, let's create the plan for what the user wants to do.
 The plan should be based on the user request found in the conversation below.
 Add items to the todo list based on the plan.
-Reference relevant resources from the project status (e.g. branchs, commits, file changes) when creating the todo items.
+Reference relevant resources from the project status (e.g. branches, commits, file changes) when creating the todo items.
 
 <CONVERSATION>
 {conversation}
@@ -356,7 +356,7 @@ Based on the conversation below and the project status, please update the status
 </TODO>
 
 <IMPORTANT_NOTES>
-Be thorough in your response. Name relevant branchs, commits, file changes, and any other relevant information.
+Be thorough in your response. Name relevant branches, commits, file changes, and any other relevant information.
 Follow best practices.
 ONLY perform the actions that are necessary to complete the todo item above.
 If you need to perform investigations, do so, and be detailed in your findings. Don't perform actions.

crates/but/src/args/mod.rs

@@ -49,7 +49,7 @@ pub enum OutputFormat {
     /// The output to write is supposed to be for human consumption, and can be more verbose.
     #[default]
     Human,
-    /// The output should be suitable for shells, and assigning the major result to variables so that it can be re-used
+    /// The output should be suitable for shells, and assigning the major result to variables so that it can be reused
     /// in subsequent CLI invocations.
     Shell,
     /// Output detailed information as JSON for tool consumption.
@@ -417,7 +417,7 @@ pub enum Subcommands {
     ///
     /// Optionally an identifier to an Uncommitted File or a Branch (stack) may be provided.
     ///
-    /// - If an Uncommitted File id is provided, absorb will be peformed for just that file
+    /// - If an Uncommitted File id is provided, absorb will be performed for just that file
     /// - If a Branch (stack) id is provided, absorb will be performed for all changes assigned to that stack
     /// - If no source is provided, absorb is performed for all uncommitted changes
     ///
@@ -494,7 +494,7 @@ pub enum Subcommands {
     #[clap(hide = true)]
     Cursor(cursor::Platform),
 
-    /// INTERNAL: GitButler Actions are automated tasks (like macros) that can be peformed on a repository.
+    /// INTERNAL: GitButler Actions are automated tasks (like macros) that can be performed on a repository.
     #[cfg(feature = "legacy")]
     #[clap(hide = true)]
     Actions(actions::Platform),

crates/but/src/command/legacy/absorb.rs

@@ -28,7 +28,7 @@ use crate::{
 ///
 /// Optionally an identifier to an Uncommitted File or a Branch (stack) may be provided.
 ///
-/// If an Uncommitted File id is provided, absorb will be peformed for just that file
+/// If an Uncommitted File id is provided, absorb will be performed for just that file
 /// If a Branch (stack) id is provided, absorb will be performed for all changes assigned to that stack
 /// If no source is provided, absorb is performed for all uncommitted changes
 pub(crate) fn handle(

crates/but/src/command/legacy/forge/review.rs

@@ -286,7 +286,7 @@ async fn publish_reviews_for_branch_and_dependents(
         if let Some(out) = out.for_human() {
             writeln!(
                 out,
-                "Publishing review for branch '{}' targetting '{}",
+                "Publishing review for branch '{}' targeting '{}",
                 head.name, current_target_branch
             )?;
         }

crates/but/src/command/legacy/mark.rs

@@ -102,7 +102,7 @@ fn mark_branch(
         return Ok(());
     }
     // TODO: if there are other marks of this kind, get rid of them
-    let stack_id = stack_id.expect("Cant find stack for this branch");
+    let stack_id = stack_id.expect("Cannot find stack for this branch");
     let action = but_rules::Action::Explicit(Operation::Assign {
         target: but_rules::StackTarget::StackId(stack_id.to_string()),
     });

crates/but/src/command/legacy/status/json.rs

@@ -128,7 +128,7 @@ pub(crate) struct Commit {
     author_name: String,
     /// The email of the commit author
     author_email: String,
-    /// Wheter the commit is in a conflicted state. Only applicable to local commits (and not to upstream commits)
+    /// Whether the commit is in a conflicted state. Only applicable to local commits (and not to upstream commits)
     conflicted: Option<bool>,
     /// If but status was invoked with --review and if the commit has an associated review ID (eg. Gerrit review number), it will be present here
     review_id: Option<String>,

crates/but/src/legacy/id/mod.rs

@@ -95,7 +95,7 @@ pub struct IdDb {
 /// Lifecycle
 impl IdDb {
     /// Initialise CLI IDs for all information in the `RefInfo` structure for `HEAD` via `ctx`.
-    // TODO: create an API that enforces re-use of `RefInfo` by its users.
+    // TODO: create an API that enforces reuse of `RefInfo` by its users.
     pub fn new(ctx: &Context) -> anyhow::Result<Self> {
         let mut max_zero_count = 1; // Ensure at least two "0" in ID.
         let context_info = context_info(ctx)?;

crates/but/src/tui/select_branch/mod.rs

@@ -66,7 +66,7 @@ pub struct TuiBranch {
 #[derive(Debug, Default)]
 pub struct TuiStack {
     /// The branches in the stack.
-    /// Orderd from child to parent.
+    /// Ordered from child to parent.
     pub branches: Vec<TuiBranch>,
 }
 

crates/gitbutler-hunk-dependency/README.md

@@ -1,6 +1,6 @@
 # Hunk dependency
 
-This crate contains the logic behind the calculation of the dependency graph between commits and between uncommited changes.
+This crate contains the logic behind the calculation of the dependency graph between commits and between uncommitted changes.
 
 ## Overview
 
@@ -16,9 +16,9 @@ We should play around with the limits of what should be rearrangeable.
 
 ### What do we want?
 
-1. Be able to tell which uncommited changes belong to which stacks.
+1. Be able to tell which uncommitted changes belong to which stacks.
 2. Be able to tell which commits depend on which preceding commits.
-3. Be able to tell which commits are depended upon by following commits or uncommited changes (i.e. the inverse map of the previous two items).
+3. Be able to tell which commits are depended upon by following commits or uncommitted changes (i.e. the inverse map of the previous two items).
 
 ### What do we need?
 
@@ -49,7 +49,7 @@ The items in the vector, i.e. hunk ranges, have the following information:
 
 ## Algorithm's pseudo code (roughly)
 
-What we're rougly doing in the code is
+What we're roughly doing in the code is
 ```
 for all affected files:
   for all input diff hunks:
@@ -61,7 +61,7 @@ for all affected files:
       override all previous hunks
       break
 
-    if there are no exsting hunks
+    if there are no existing hunks
       add all diffs (can be multiple)
       break
 
@@ -189,12 +189,12 @@ After processing the incoming hunk, the hunk range list looks like this
 The existing range was split, and the incoming hunk split the existing range into the first and the last one.
 The index of the next hunk range to visit is `2` and the index of the first hunk to shift is `3`.
 When we process a following hunk, we need to compare it to the **3rd hunk range** (and following hunk ranges if any), but we need to shift the `start` lines of the hunk ranges following the ones we updated, in this case the **4th hunk range**.
-Since the net lines are 0, everythin stays as is.
+Since the net lines are 0, everything stays as is.
 
 ### Multiple shifts per commit
 ---
 
-Inside a commit, multple hunks will most probably shift the lines different amounts.
+Inside a commit, multiple hunks will most probably shift the lines different amounts.
 We keep track of the cumulative line shift, and update only the hunks that follow the hunk that introduced the shift.
 
 ### Matching incoming hunks to shifted ranges