docs: Remove trailing whitespace in markdown files

CHANGELOG.md

@@ -23,11 +23,11 @@ to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 * `jj branch` has been deprecated in favor of `jj bookmark`.
 
-  **Rationale:** Jujutsu's branches don't behave like Git branches, which a 
+  **Rationale:** Jujutsu's branches don't behave like Git branches, which a
   confused many newcomers, as they expected a similar behavior given the name.
   We've renamed them to "bookmarks" to match the actual behavior, as we think
-  that describes them better, and they also behave similar to Mercurial's 
-  bookmarks. 
+  that describes them better, and they also behave similar to Mercurial's
+  bookmarks.
 
 * The `git.push-branch-prefix` config has been deprecated in favor of
   `git.push-bookmark-prefix`.
@@ -87,7 +87,7 @@ to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 * A tilde (`~`) at the start of the path will now be expanded to the user's home
   directory when configuring a `signing.key` for SSH commit signing.
-  
+
 * When reconfiguring the author, warn that the working copy won't be updated
 
 ### Fixed bugs
@@ -187,7 +187,7 @@ Thanks to the people who made this release happen!
 
 * `jj backout` can now back out multiple commits at once.
 
-* `jj git clone some/nested/path` now creates the full directory tree for 
+* `jj git clone some/nested/path` now creates the full directory tree for
    nested destination paths if they don't exist.
 
 * String patterns now support case‐insensitive matching by suffixing any

README.md

@@ -132,32 +132,32 @@ developers monitor both channels.
 ### News and Updates 📣
 
 - **Feb 2024**: Version 0.14 is released, which deprecates ["jj checkout" and "jj merge"](CHANGELOG.md#0140---2024-02-07),
-  as well as `jj init --git`, which is now just called `jj git init`. 
+  as well as `jj init --git`, which is now just called `jj git init`.
 - **Oct 2023**: Version 0.10.0 is released! Now includes a bundled merge and
   diff editor for all platforms, "immutable revsets" to avoid accidentally
   `edit`-ing the wrong revisions, and lots of polish.
 - **Jan 2023**: Martin gave a presentation about Google's plans for Jujutsu at
-  Git Merge 2022! 
+  Git Merge 2022!
   See the [slides][merge-slides] or the [recording][merge-talk].
 
 ### Related Media
 
 - **Mar 2024**: Chris Krycho started [a YouTube series about Jujutsu][krycho-yt].
 - **Feb 2024**: Chris Krycho published an article about Jujutsu called [jj init][krycho]
-  and Steve Klabnik followed up with the [Jujutsu Tutorial][klabnik]. 
-- **Jan 2024**: Jujutsu was featured in an LWN.net article called 
+  and Steve Klabnik followed up with the [Jujutsu Tutorial][klabnik].
+- **Jan 2024**: Jujutsu was featured in an LWN.net article called
   [Jujutsu: a new, Git-compatible version control system][lwn].
-- **Jan 2023**: Martin's Talk about Jujutsu at Git Merge 2022, [video][merge-talk] 
+- **Jan 2023**: Martin's Talk about Jujutsu at Git Merge 2022, [video][merge-talk]
   and the associated [slides][merge-slides].
 
 The wiki also contains a more extensive list of [media references][wiki-media].
 
 [krycho-yt]: https://www.youtube.com/playlist?list=PLelyiwKWHHAq01Pvmpf6x7J0y-yQpmtxp
 [krycho]: https://v5.chriskrycho.com/essays/jj-init/
 [klabnik]: https://steveklabnik.github.io/jujutsu-tutorial/
-[lwn]: https://lwn.net/Articles/958468/ 
+[lwn]: https://lwn.net/Articles/958468/
 [merge-talk]: https://www.youtube.com/watch?v=bx_LGilOuE4
-[merge-slides]: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/view 
+[merge-slides]: https://docs.google.com/presentation/d/1F8j9_UOOSGUN9MvHxPZX_L4bQ9NMcYOp1isn17kTC_M/view
 [wiki-media]: https://github.com/martinvonz/jj/wiki/Media
 
 ## Getting started
@@ -209,7 +209,7 @@ The Git backend is fully featured and maintained, and allows you to use Jujutsu
 with any Git remote. The commits you create will look like regular Git commits.
 You can fetch branches from a regular Git remote and push branches to the
 remote. You can always switch back to Git.
- 
+
 Here is how you can explore a GitHub repository with `jj`.
 
 <img src="demos/git_compat.png" />

cli/src/config/README.md

@@ -1,2 +1,2 @@
 These files are compiled into the binary; they are not installed to the user's
-system.
+system.

docs/FAQ.md

@@ -66,18 +66,18 @@ important ones are:
 
 - Jujutsu commands may be a little slower in very large repositories due to
   importing and exporting changes to Git. Most repositories are not noticeably
-  affected by this. 
+  affected by this.
 
 If you primarily use Jujutsu to modify the repository, the drawbacks are
 unlikely to affect you. Try co-locating while you learn Jujutsu, then switch if
 you find a specific reason not to co-locate.
 
-### `jj` is said to record the working copy after `jj log` and every other command. Where can I see these automatic "saves"?  
+### `jj` is said to record the working copy after `jj log` and every other command. Where can I see these automatic "saves"?
 
-Indeed, every `jj` command updates the current "working-copy" revision, marked 
+Indeed, every `jj` command updates the current "working-copy" revision, marked
 with `@` in `jj log`. You can notice this by how the [commit ID] of the
 working copy revision changes when it's updated. Note that, unless you move to
-another revision (with `jj new` or `jj edit`, for example), the [change ID] will 
+another revision (with `jj new` or `jj edit`, for example), the [change ID] will
 not change.
 
 If you expected to see a historical view of your working copy changes in the
@@ -151,9 +151,9 @@ ignore everything in the directory including the `.gitignore` file itself.
 
 If `$EDITOR` integration is important, something like `scratchpad.*` may be more
 helpful, as you can keep the filename extension intact (it
-matches `scratchpad.md`, `scratchpad.rs` and more). Another option is to add a 
+matches `scratchpad.md`, `scratchpad.rs` and more). Another option is to add a
 directory to the global `.gitignore` which then stores all your temporary files
-and notes. For example, you could add `scratch/` to `~/.git/ignore` and then 
+and notes. For example, you could add `scratch/` to `~/.git/ignore` and then
 store arbitrary files in `<your-git-repo>/scratch/`.
 
 You can find more details on `gitignore` files [here][gitignore].
@@ -163,7 +163,7 @@ You can find more details on `gitignore` files [here][gitignore].
 Suppose your repository tracks a file like `secret_config.json`, and you make
 some changes to that file to work locally. Since Jujutsu automatically commits
 the working copy, there's no way to prevent Jujutsu from committing changes to
-the file. But, you never want to push those changes to the remote repository. 
+the file. But, you never want to push those changes to the remote repository.
 
 One solution is to keep these changes in a separate commit branched from the
 trunk. To use those changes in your working copy, _merge_ the private commit
@@ -251,15 +251,15 @@ commit to the new state.
 ### How do I resume working on an existing change?
 
 There are two ways to resume working on an earlier change: `jj new` then `jj squash`,
-and `jj edit`. The first is generally recommended, but `jj edit` can be useful. When 
+and `jj edit`. The first is generally recommended, but `jj edit` can be useful. When
 you use `jj edit`, the revision is directly amended with your new changes, making it
 difficult to tell what exactly you change. You should avoid using `jj edit` when the
 revision has a conflict, as you may accidentally break the plain-text annotations on
 your state without realising.
 
 To start, use `jj new <rev>` to create a change based on that earlier revision. Make
 your edits, then use `jj squash` to update the earlier revision with those edits.
-For when you would use git stashing, use `jj edit <rev>` for expected behaviour. 
+For when you would use git stashing, use `jj edit <rev>` for expected behaviour.
 Other workflows may prefer `jj edit` as well.
 
 ### How do I deal with divergent changes ('??' after the [change ID])?

docs/cli-reference.md

@@ -18,4 +18,3 @@
   rewrite-relative-urls=false
   start="<!-- BEGIN MARKDOWN-->"
 %}
-

docs/community_tools.md

@@ -4,16 +4,16 @@
 But they already simplify many workflows and can improve your experience.
 
 
-## Diffedit3 
+## Diffedit3
 
-Diffedit3 is a web-based alternate to Meld, as it no longer is packaged and 
+Diffedit3 is a web-based alternate to Meld, as it no longer is packaged and
 available for all Distros. Its creator is also a frequent contributor.
 
 Find it [here][diffedit3]
 
 ## GG - GUI for JJ
 
-GG is a cross platform GUI for Jujutsu which makes all graph manipulating 
+GG is a cross platform GUI for Jujutsu which makes all graph manipulating
 workflows quite easy. Take a look at its README.md as it quite descriptive.
 
 Find it [here][gg].
@@ -33,30 +33,30 @@ Find it [here][lazyjj].
 
 ## JJ TUI
 
-This is TUI for Jujutsu built in Ocaml, it is unopiniated and its creator is 
+This is TUI for Jujutsu built in Ocaml, it is unopiniated and its creator is
 open to feedback.
 
 Find it [here][jj_tui].
 
 
 ## Visual Jujutsu
 
-VJJ is a fzf (fuzzy finder) wrapper for Jujutsu, which is meant to be used 
-interactively in the terminal. 
+VJJ is a fzf (fuzzy finder) wrapper for Jujutsu, which is meant to be used
+interactively in the terminal.
 
 Find it [here][vjj].
 
 <!-- TODO: Add benbrittains/cultivate when its ready -->
-## Finding other integrations 
+## Finding other integrations
 
-You can find other community contributed tools and integrations in our 
+You can find other community contributed tools and integrations in our
 [Wiki].
 
 [cultivate]: https://github.com/benbrittain/cultivate
 [diffedit3]: https://github.com/ilyagr/diffedit3
-[gg]: https://github.com/gulbanana/gg 
+[gg]: https://github.com/gulbanana/gg
 [hunk.nvim]: https://github.com/julienvincent/hunk.nvim
 [jj_tui]: https://github.com/faldor20/jj_tui
 [lazyjj]: https://github.com/Cretezy/lazyjj
 [vjj]: https://github.com/noahmayr/vjj
-[Wiki]: https://github.com/martinvonz/jj/wiki 
+[Wiki]: https://github.com/martinvonz/jj/wiki

docs/config.md

@@ -771,7 +771,7 @@ patterns = ["numbers.txt"]
 
 ## Commit Signing
 
-`jj` can be configured to sign and verify the commits it creates using either 
+`jj` can be configured to sign and verify the commits it creates using either
 GnuPG or SSH signing keys.
 
 To do this you need to configure a signing backend.
@@ -824,8 +824,8 @@ signing.backends.ssh.program = "/path/to/ssh-keygen"
 When verifying commit signatures the ssh backend needs to be provided with an allowed-signers
 file containing the public keys of authors whose signatures you want to be able to verify.
 
-You can find the format for this file in the 
-[ssh-keygen man page](https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS). This can be provided 
+You can find the format for this file in the
+[ssh-keygen man page](https://man.openbsd.org/ssh-keygen#ALLOWED_SIGNERS). This can be provided
 as follows:
 
 ```toml

docs/contributing.md

@@ -36,22 +36,22 @@ commit and the new feature in a different commit. If the refactoring itself
 consists of many parts, try to separate out those into separate commits. You can
 use `jj split` to do it if you didn't realize ahead of time how it should be
 split up. Include tests and documentation in the same commit as the code they
-test and document. 
+test and document.
 
 The commit message should describe the changes in the commit;
 the PR description can even be empty, but feel free to include a personal
-message. We write commit messages in an affected component style and don't use 
-[conventional commits](www.conventionalcommits.org/en/v1.0.0/). This means if 
-you modified a command in the CLI, use its name as the topic, e.g 
+message. We write commit messages in an affected component style and don't use
+[conventional commits](www.conventionalcommits.org/en/v1.0.0/). This means if
+you modified a command in the CLI, use its name as the topic, e.g
 `next/prev: <your-modification>` or `conflicts: <your-modification>`. We don't
-currently have a specific guidelines on what to write in the topic field, but 
-the reviewers will help you provide a topic if you have difficulties choosing 
+currently have a specific guidelines on what to write in the topic field, but
+the reviewers will help you provide a topic if you have difficulties choosing
 it.
 
 When you address comments on a PR, don't make the changes in a commit on top (as
 is typical on GitHub). Instead, please make the changes in the appropriate
-commit. You can do that by creating a new commit on top of the initial commit 
- (`jj new <commit>`) and then squash in the changes when you're done (`jj squash`). 
+commit. You can do that by creating a new commit on top of the initial commit
+ (`jj new <commit>`) and then squash in the changes when you're done (`jj squash`).
 `jj git push`
 will automatically force-push the bookmark.
 
@@ -74,9 +74,9 @@ Guidelines](https://opensource.google/conduct/).
 
 ## Contributing large patches
 
-Before sending a PR for a large change which designs/redesigns or reworks an 
-existing component, we require an architecture review from  multiple 
-stakeholders, which we do with [Design Docs](design_docs.md), see the 
+Before sending a PR for a large change which designs/redesigns or reworks an
+existing component, we require an architecture review from  multiple
+stakeholders, which we do with [Design Docs](design_docs.md), see the
 [process here](design_docs.md#process).
 
 ## Contributing to the documentation
@@ -233,7 +233,7 @@ necessary. Any version of `pipx` will do. If you are installing `pipx` manually,
 you may first need to follow the [Python installation instructions].
 
 [Python installation instructions]: https://docs.python.org/3/using/index.html
-[Poetry installation instructions]: https://python-poetry.org/docs/#installation 
+[Poetry installation instructions]: https://python-poetry.org/docs/#installation
 
 Once you have `poetry` installed, you should ask it to install the rest
 of the required tools into a virtual environment as follows:

docs/design/copy-tracking.md

@@ -75,12 +75,12 @@ pub type CopyRecordStream = BoxStream<BackendResult<CopyRecord>>;
 
 pub trait Backend {
     /// Get all copy records for `paths` in the dag range `roots..heads`.
-    /// 
+    ///
     /// The exact order these are returned is unspecified, but it is guaranteed
     /// to be reverse-topological. That is, for any two copy records with
     /// different commit ids A and B, if A is an ancestor of B, A is streamed
     /// after B.
-    /// 
+    ///
     /// Streaming by design to better support large backends which may have very
     /// large single-file histories. This also allows more iterative algorithms
     /// like blame/annotate to short-circuit after a point without wasting