Merge pull request #1587 from jayvdb/typos

Fix typos

.github/workflows/release.yml

@@ -368,7 +368,7 @@ jobs:
       - name: Show all individual asset names
         run: cat assets.txt
 
-      # The `features` array is repeated because GHA doen't support YAML anchors.
+      # The `features` array is repeated because GHA doesn't support YAML anchors.
       # We will check that the macOS `universal` features match the others exactly.
       # In the future this and the next step may be removed, or expanded to do more validation.
       - name: Extract macOS asset names by architecture

etc/monthlies/2021/july.md

@@ -4,7 +4,7 @@ Even though in June the foundation was set with `git-tempfile` and `git-lock`, c
 
 One of the ways to accomplish this is to use transactions, a bundle of edits, which we try hard to perform in a way that can be rolled back on error. It works by preparing each updated or soon-to-be-deleted ref with a lock file to block other writes which receives updates in place of the actual reference. Under most circumstances, a reflog is written as well which is supposedly guarded by the same lock.  Once all lock files have been created, the transaction can be committed by moving all locks onto the reference they lock or by removing the reference accordingly. There is a ton of edge cases that are tested for and handled faithfully, even though ultimately these transactions aren't really transactional as many non-atomic operations are involved.
 
-As a side-effect of this, reflogs can now be written, iterated in various ways, and packed-refs are incorporated into find results or when iterating references. As always, `gitoxide` choses not to handle caches internally but delegates this to the user. For all one-off operation this feels very natural, whereas long-running tools will most certainly get to resort to `git-repository` in some shape or form.
+As a side-effect of this, reflogs can now be written, iterated in various ways, and packed-refs are incorporated into find results or when iterating references. As always, `gitoxide` chooses not to handle caches internally but delegates this to the user. For all one-off operation this feels very natural, whereas long-running tools will most certainly get to resort to `git-repository` in some shape or form.
 
 For fun I have run very unscientific benchmarks and saw ~6mio packed references traversed per second, along with 500.000 packed reference lookups per second, per core.
 

etc/monthlies/2021/may.md

@@ -25,7 +25,7 @@ A new release was cut with a bunch of new user-facing features. The most notable
 
 ### Everything else
 
-GitPython took some time to maintain and there has been some back and forth with me trying to cut a release and immediately yanking it a few hours later due to unforseen breakage. The main cause was the addition of types, and another my inability to properly review python code.
+GitPython took some time to maintain and there has been some back and forth with me trying to cut a release and immediately yanking it a few hours later due to unforeseen breakage. The main cause was the addition of types, and another my inability to properly review python code.
 
 As a major change of attitude I stopped considering GitPython a burden that I keep around like the 30 year old child that lives in the basement and really doesn't want to leave. Instead I see its massive user base as asset and plan to overhaul it with a new, and hopefully the last, major version that is literally gitoxides python bindings. Even thinking about it, it seems a little bit forced to turn GitPython into something else entirely, but that seems more sustainable than keeping GitPython around in its current form any longer.
 In other words, GitPython can help push gitoxide to the masses and maybe even become the best, fastest, safest and most convenient way to interact with git repositories (besides using Rust directly, of course ;)).

etc/monthlies/2022/april.md

@@ -61,7 +61,7 @@ Now all crates which use an `FnMut(oid, buf) -> Option<Object>` closure have bee
 
 While improving the API surface of `git-repository` to be more useful for prospect users of the crates I also had to find definitive answers to how to expose object information. The question really was whether to expose the underlying object, or to return wrapped higher-level objects instead for convenience.
 
-The answer now is usually: 'both', while avoiding any allocation when extracting fields of objects like commits by default. This is a trade-off geared towards leveraging the incredibly fast object parsing performance while avoiding memory fragmentation for allocations which could otherwise occour. This is done using the object iterators, that lazily return one decoded token at a time. That way one can stop decoding once the field of interest is reached, but one will also decode portions of the object multiple times if more than one field is requested.
+The answer now is usually: 'both', while avoiding any allocation when extracting fields of objects like commits by default. This is a trade-off geared towards leveraging the incredibly fast object parsing performance while avoiding memory fragmentation for allocations which could otherwise occur. This is done using the object iterators, that lazily return one decoded token at a time. That way one can stop decoding once the field of interest is reached, but one will also decode portions of the object multiple times if more than one field is requested.
 
 This also means that users who want to access all fields of a commit, for example, are probably better off decoding the commit once and using the lower-level commit from the `git-object` crate, which is fully decoded once.
 
@@ -74,7 +74,7 @@ Additionally, all these object-decode-iterators will not squelch decode errors a
 Out of a desire to improve performance, the `onefetch` maintainers reached out to see if they could use `gitoxide` instead.
 I went right to work which results in this PR being merged: https://github.com/o2sh/onefetch/pull/635 and me being a collaborator. `onefetch` is now ~2.2x faster in the repositories I tested and is more correct as well.
 
-`git2`, however, is still needed for accessing the git configuration, so some more work is still waiting to be done to complete the transision from `git2` to `gitoxide` ([tracking issue](https://github.com/Byron/gitoxide/issues/364)).
+`git2`, however, is still needed for accessing the git configuration, so some more work is still waiting to be done to complete the transition from `git2` to `gitoxide` ([tracking issue](https://github.com/Byron/gitoxide/issues/364)).
 
 #### `git-mailmap`
 

etc/monthlies/2022/august.md

@@ -47,7 +47,7 @@ What's notable is its performance, as when constructing worst-case scenarios wit
 
 ## The flattening of `gix repo`
 
-With `gix` gaining more and more commands that are benefiting from `git-repository`, it seemed only reasonable to make these commands more accesible as well by removing the `repo` sub-command and folding all commands that need a repository to the top-level. This also means that all commands that where there previously have now been placed under the `no-repo|free` sub-command. These of course still have their use but will be generally be more niche than what's now on the top-level. Definitely a win for ergonomics.
+With `gix` gaining more and more commands that are benefiting from `git-repository`, it seemed only reasonable to make these commands more accessible as well by removing the `repo` sub-command and folding all commands that need a repository to the top-level. This also means that all commands that where there previously have now been placed under the `no-repo|free` sub-command. These of course still have their use but will be generally be more niche than what's now on the top-level. Definitely a win for ergonomics.
 
 ## complete `ref-spec` parsing
 

etc/monthlies/2022/february.md

@@ -1,4 +1,4 @@
-[Gitoxide in Febuary]: `gix index` sub-command, more contributions along with a new close contributor
+[Gitoxide in February]: `gix index` sub-command, more contributions along with a new close contributor
 
 ### The new `gix index` sub-command
 

etc/monthlies/2022/july.md

@@ -4,10 +4,10 @@ And the one crate that has been a huge thorn in my eye was `git-config`, so I th
 
 ## Pushing `git-config` towards 1.0
 
-While Svetlin was already making valuable contributions to add support for handling `include.path` and conditional includes via `includeIf`, the crate lacked behind in 'style', naming, and code structure, while being generally quite unknown to me which I considered technical debt. When taking out the loan by merging without proper review, I was quite aware one day it had to be payed back. 
+While Svetlin was already making valuable contributions to add support for handling `include.path` and conditional includes via `includeIf`, the crate lacked behind in 'style', naming, and code structure, while being generally quite unknown to me which I considered technical debt. When taking out the loan by merging without proper review, I was quite aware one day it had to be paid back.
 So I started combing through each line of code to not only make it similar in structure to the ones in its sibling crates, but also to validate their functionality. All 4500 lines!
 
-###### testing 
+###### testing
 
 In the course of this, 127 tests were added on top of the already impressive test suite to nearly 300, luring out a surprising amount of bugs in all levels of the library. I also revived and for the first time ran the fuzzer, powered by `cargo-fuzz`, to try over a billion different inputs for the parser. That run though was after it immediately found a crash in the parser, showing me that from now on fuzzing of parsers will be standard fare. Thanks to `cargo fuzz` it's also super easy to do, something that is a game changer for me as someone who always thought it must be too complicated to setup.
 
@@ -41,7 +41,7 @@ This section I want to keep in all sponsor updates moving forward to the end of
 
 Early after the grant timeframe began I reached out via the shallow clone ticket to get a conversation going on how to proceed, but will have to try harder to reach the folks who can provide the answers. Even though I took some liberty in finishing `git-config` it's clear that soon I have to align my work towards integrating `gitoxide` into `cargo` with or without feedback, to be able to implement what's needed to make it superior to what `git2` is currently offering.
 
-At this time there is no reason to worry, but the clock is ticking for me :D. 
+At this time there is no reason to worry, but the clock is ticking for me :D.
 
 ## Outlook
 

etc/monthlies/2022/november.md

@@ -72,7 +72,7 @@ One of its major benefits is that its author, [Pascal Kuthe](https://github.com/
 ## `crates-index-diff` performance and correctness upgrade ([docs.rs](http://docs.rs/) team work)
 
 `crates-index-diff` was able to miss changes which caused a single crate version not to be built (as far as we know, at least), and that was quite a shock as I spent a lot of time already to isolate the test suite and test everything…except for certain edge cases apparently. Thanks to said test system it was possible to add the issue at hand as fixture for a reproduction. Fixing the issue was possible, but it was clear that the current diff implementation couldn't really be trusted. Who could know if such an issue 
-couldn't happen agin?
+couldn't happen again?
 
 So I started to [work furiously](https://github.com/Byron/crates-index-diff-rs/issues/26) on solving the issue… by asking for help! [Pascal Kuthe](https://github.com/pascalkuthe) answered the call and completely redesigned the diffing algorithm within hours (and mostly at night!) into something that is faster AND simpler AND logically correct.
 

etc/monthlies/2022/september.md

@@ -35,7 +35,7 @@ A neat optimization is also implemented, as the protocol V2 supports the special
 
 ### Celebrating 100k lines of code
 
-In case you have missed it, here is the post [on reddit](https://www.reddit.com/r/rust/comments/xj6ncq/media_gitoxide_celebrating_100k_lines_of_rust_code/). This has to come with the correction that it is in fact just code, not Rust code exlusively. Tokei now reports 95k of Rust, so nearly there.
+In case you have missed it, here is the post [on reddit](https://www.reddit.com/r/rust/comments/xj6ncq/media_gitoxide_celebrating_100k_lines_of_rust_code/). This has to come with the correction that it is in fact just code, not Rust code exclusively. Tokei now reports 95k of Rust, so nearly there.
 
 `codevis`, the tool behind the picture, was irresistible to me as it produces pretty visualizations and is hackable! After trying it I was inspired and wanted to play more, so I added `clap` to what was just a pre-configured program before. From there, I ended up adding `prodash` for nicer progress, multi-threading and various optimizations to be able to render pictures of any size even on memory constrained systems.
 

etc/monthlies/2023/october.md

@@ -31,7 +31,7 @@ I even tried to change the mode of parallelism to match the one of `git` so the
 
 ### Packetline tracing
 
-A hang could occour when fetching via `file://` or `ssh://` (and possibly `git://` ) *and* the V1 protocol and [it took a long time]((https://github.com/Byron/gitoxide/issues/1061)) to figure out a fix.
+A hang could occur when fetching via `file://` or `ssh://` (and possibly `git://` ) *and* the V1 protocol and [it took a long time]((https://github.com/Byron/gitoxide/issues/1061)) to figure out a fix.
 
 One step on the way was to finally make it possible to observe all packetlines as they are sent over the wire just like `GIT_TRACE_PACKET` does for `git`. As `gix` integrates this with its tracing engine which supports structure and hierarchy, it looks really *nice* and it becomes immediately obvious which lines are sent along with which ‘stage’ of the protocol.
 

etc/monthlies/2023/september.md

@@ -46,7 +46,7 @@ Another side-effect of this work is that we thought once again how error handlin
 
 Enter [`therror`](https://github.com/Byron/therror), which could one day be the `thiserror` we always wanted. Because as it turns out, even though `thiserror` is exactly what I'd expect from error handling in a library, having these detailed, three-like errors made of enums is also a lot of work to maintain and quite cumbersome to match on. 
 
-That's two problems that need solving. For one, what if there was a programatically accessible tree of errors, so it can be queried at runtime? This would have the advantage that changes in errors don't break compiles anymore, even though failures would then be likely to occur at runtime or or consuming code simply doesn't work anymore.
+That's two problems that need solving. For one, what if there was a programmatically accessible tree of errors, so it can be queried at runtime? This would have the advantage that changes in errors don't break compiles anymore, even though failures would then be likely to occur at runtime or or consuming code simply doesn't work anymore.
 
 Secondly, what if one could just declare and pass any kind of error information along right where it happens so building errors made of enums isn't needed in the first place?
 
@@ -95,4 +95,4 @@ There was no progress here, unfortunately, `gix reset` is a prerequisite to brin
 Cheers,
 Sebastian
 
-PS: The latest timesheets can be found [here](https://github.com/Byron/byron/blob/main/timesheets/2023.csv).
+PS: The latest timesheets can be found [here](https://github.com/Byron/byron/blob/main/timesheets/2023.csv).

gix-fs/tests/stack/mod.rs

@@ -256,7 +256,7 @@ fn absolute_paths_are_invalid() -> crate::Result {
     assert_eq!(
         s.current(),
         p("./b\\"),
-        "trailing backslashes are fine both on Windows and Unix - on Unix it's part fo the filename"
+        "trailing backslashes are fine both on Windows and Unix - on Unix it's part of the filename"
     );
 
     #[cfg(windows)]

gix-index/CHANGELOG.md

@@ -1735,7 +1735,7 @@ A maintenance release without user-facing changes.
     - Support for extended flags, and V3 as it's a requirements. ([`417d90e`](https://github.com/Byron/gitoxide/commit/417d90eb267dd74a5372f1c7d8feb7cb4e98d2a1))
     - Refcator ([`27993c0`](https://github.com/Byron/gitoxide/commit/27993c01a1533d561629635336c5cedf53dd0efc))
     - Fix tree ext reading and writing; round-trip with long path works now ([`f93febe`](https://github.com/Byron/gitoxide/commit/f93febe2d2c55938ac8f698b57144583caab54ef))
-    - First PoC for writing long paths, even though it doens't produce the entire file yet ([`581cbd7`](https://github.com/Byron/gitoxide/commit/581cbd7afeac0f7654611c83deacae802ef5da6f))
+    - First PoC for writing long paths, even though it doesn't produce the entire file yet ([`581cbd7`](https://github.com/Byron/gitoxide/commit/581cbd7afeac0f7654611c83deacae802ef5da6f))
     - Make it more explicit to write all available extensions by default ([`fbe9815`](https://github.com/Byron/gitoxide/commit/fbe981519446e55c4020e95841e7bff7e54e358e))
     - Fix docs ([`9861a6c`](https://github.com/Byron/gitoxide/commit/9861a6ce8abc438a1e0739aa6d55ced450a4465b))
     - Thanks clippy ([`834be93`](https://github.com/Byron/gitoxide/commit/834be93e6db84bb9160dd4677b7e9d63213c23cd))

gix-ref/CHANGELOG.md

@@ -2080,7 +2080,7 @@ A maintenance release without user-facing changes.
     - [ref #139] peeling for all refs to be written to a pack ([`cc891a1`](https://github.com/Byron/gitoxide/commit/cc891a1809a6678f168b08766f67644742386a5d))
     - [ref #139] refactor ([`7e15817`](https://github.com/Byron/gitoxide/commit/7e1581788356889a936f4a778119b0bce36d3041))
     - [ref #139] Allow packed-refs creation in the presence of updates ([`0cf7314`](https://github.com/Byron/gitoxide/commit/0cf7314df7a6ab79478525544e0ed28d07cf3642))
-    - [ref #139] impl of loose ref deletion, but it doens't work yet… ([`f6631ad`](https://github.com/Byron/gitoxide/commit/f6631ad537b4c7fd6dec2a511214552e606462d4))
+    - [ref #139] impl of loose ref deletion, but it doesn't work yet… ([`f6631ad`](https://github.com/Byron/gitoxide/commit/f6631ad537b4c7fd6dec2a511214552e606462d4))
     - [ref #139] a failing test for pruning loose refs into packed refs ([`437c610`](https://github.com/Byron/gitoxide/commit/437c610eeb3b4a5874f001ba6fbbd42c7dc1188e))
     - [ref #139] refactor ([`62558cb`](https://github.com/Byron/gitoxide/commit/62558cb562747d3c6f2b4e1b62dd44e4f1e95019))
     - [ref #139] a first sketch to resolve object chains for packed ref peeling ([`54bc116`](https://github.com/Byron/gitoxide/commit/54bc1161128f0c719622935728a870820918038b))

gix-revision/src/merge_base.rs

@@ -215,7 +215,7 @@ pub(crate) mod function {
     #[derive(Debug, Clone, Copy)]
     struct GenThenTime {
         /// Note that the special [`GENERATION_NUMBER_INFINITY`](gix_commitgraph::GENERATION_NUMBER_INFINITY) is used to indicate
-        /// that no commitgraph is avaialble.
+        /// that no commitgraph is available.
         generation: gix_revwalk::graph::Generation,
         time: gix_date::SecondsSinceUnixEpoch,
     }

gix-transport/src/client/git/mod.rs

@@ -114,7 +114,7 @@ mod message {
             );
         }
         #[test]
-        fn version_2_without_host_and_version_and_exta_parameters() {
+        fn version_2_without_host_and_version_and_extra_parameters() {
             assert_eq!(
                 git::message::connect(
                     Service::UploadPack,

gix-validate/src/tag.rs

@@ -34,7 +34,7 @@ pub mod name {
 }
 
 /// Assure the given `input` resemble a valid git tag name, which is returned unchanged on success.
-/// Tag names are provided as names, lik` v1.0` or `alpha-1`, without paths.
+/// Tag names are provided as names, like `v1.0` or `alpha-1`, without paths.
 pub fn name(input: &BStr) -> Result<&BStr, name::Error> {
     match name_inner(input, Mode::Validate)? {
         None => Ok(input),

gix-worktree-state/tests/fixtures/make_dangling_symlink_to_windows_reserved.sh

@@ -10,4 +10,4 @@ git update-index --index-info <<EOF
 120000 $con_oid	dangling-con-symlink
 EOF
 
-git commit -m "dangling symlinks with Widnows reserved target in index"
+git commit -m "dangling symlinks with Windows reserved target in index"