Use en_US for spelling

docs/src/SUMMARY.md

@@ -10,7 +10,7 @@
 - [Git Worktrees](./worktrees.md)
   - [Working with Worktrees](./worktree_working.md)
   - [Worktrees and Remotes](./worktree_remotes.md)
-  - [Behaviour Details](./worktree_behaviour.md)
+  - [Behavior Details](./worktree_behavior.md)
 - [FAQ](./faq.md)
 - [Developer Documentation](./developing.md)
   - [Testing](./testing.md)

docs/src/testing.md

@@ -16,7 +16,7 @@ functions (like validation of certain input).
 ## E2E tests
 
 The main focus of the testing setup lays on the e2e tests. Each user-facing
-behaviour *should* have a corresponding e2e test. These are the most important
+behavior *should* have a corresponding e2e test. These are the most important
 tests, as they test functionality the user will use in the end.
 
 The test suite is written in python and uses
@@ -28,7 +28,7 @@ Effectively, each tests works like this:
 * Set up some prerequisites (e.g. different git repositories or configuration
   files)
 * Run `grm`
-* Check that everything is according to expected behaviour (e.g. that `grm` had
+* Check that everything is according to expected behavior (e.g. that `grm` had
   certain output and exit code, that the target repositories have certain
   branches, heads and remotes, ...)
 
@@ -39,8 +39,8 @@ configuration exists, what a config value is set to, how the repository looks
 like, ...)
 
 Whenever you write a new test, think about the different circumstances that can
-happen. What are the failure modes? What affects the behaviour? Parametrize each
+happen. What are the failure modes? What affects the behavior? Parametrize each
-of these behaviours.
+of these behaviors.
 
 ### Optimization
 

e2e_tests/test_worktrees.py

@@ -70,7 +70,7 @@ def test_worktree_add(
         explicit_track_branch_name = f"{default_remote}/{worktree_name}"
 
     timestamp = datetime.datetime.now().replace(microsecond=0).isoformat()
-    # GitPython has some weird behaviour here. It is not possible to use kwargs
+    # GitPython has some weird behavior here. It is not possible to use kwargs
     # to set the commit and author date.
     #
     # `committer_date=x` (which is documented) does not work, as `git commit`
@@ -79,7 +79,7 @@ def test_worktree_add(
     # `author_date=x` does not work, as it's now called --date in `git commit`
     #
     # `date=x` should work, but is refused by GitPython, as it does not know
-    # about the new behaviour in `git commit`
+    # about the new behavior in `git commit`
     #
     # Fortunately, there are env variables that control those timestamps.
     os.environ["GIT_COMMITTER_DATE"] = str(timestamp)

src/repo.rs

@@ -233,7 +233,7 @@ impl Worktree {
                     let operation = operation.map_err(convert_libgit2_error)?;
 
                     // This is required to preserve the commiter of the rebased
-                    // commits, which is the expected behaviour.
+                    // commits, which is the expected behavior.
                     let rebased_commit = repo
                         .0
                         .find_commit(operation.id())
@@ -357,7 +357,7 @@ impl Worktree {
             let operation = operation.map_err(convert_libgit2_error)?;
 
             // This is required to preserve the commiter of the rebased
-            // commits, which is the expected behaviour.
+            // commits, which is the expected behavior.
             let rebased_commit = repo
                 .0
                 .find_commit(operation.id())

src/worktree.rs

@@ -81,9 +81,9 @@
 //! * Instead of just picking `origin/prefix/foobar`, grm will complain because
 //!   it also selected `remote2/foobar`.
 //!
-//! This is just emergent behaviour of the logic above. Fixing it would require
+//! This is just emergent behavior of the logic above. Fixing it would require
 //! additional logic for that edge case. I assume that it's just so rare to get
-//! that behaviour that it's acceptable for now.
+//! that behavior that it's acceptable for now.
 //!
 //! Now we either have a commit, we aborted, or we do not have commit. In the
 //! last case, as stated above, we check out the "default" branch.
@@ -137,7 +137,7 @@
 //! `foobar`. As both `remote1/foobar` and `remote2/foobar` as the same, the new
 //! worktree will use that as the state of the new branch. But as `grm` cannot
 //! tell which remote branch to track, it will not set up remote tracking. This
-//! behaviour may be a bit confusing, but first, there is no good way to resolve
+//! behavior may be a bit confusing, but first, there is no good way to resolve
 //! this, and second, the situation should be really rare (when having multiple
 //! remotes, you would generally have a `default_remote` configured).
 //!
@@ -463,7 +463,7 @@ impl<'a> Worktree<'a, WithRemoteTrackingBranch<'a>> {
                 //
                 // > failed to make directory '/{repo}/.git-main-working-tree/worktrees/dir/test
                 //
-                // This is a discrepancy between the behaviour of libgit2 and the
+                // This is a discrepancy between the behavior of libgit2 and the
                 // git CLI when creating worktrees with slashes:
                 //
                 // The git CLI will create the worktree's configuration directory