From a76ecb4d727cd4a7635c572edd91098b2bc6a6c8 Mon Sep 17 00:00:00 2001 From: Vincent Ging Ho Yim Date: Fri, 19 Jul 2024 21:15:55 +1000 Subject: [PATCH] docs: fix spelling and punctuation --- docs/config.md | 10 +++++----- docs/contributing.md | 6 +++--- docs/git-compatibility.md | 2 +- docs/glossary.md | 6 +++--- docs/revsets.md | 2 +- docs/sapling-comparison.md | 26 +++++++++++++------------- docs/templates.md | 2 +- 7 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/config.md b/docs/config.md index 01bf4c58542..8970bcfb89b 100644 --- a/docs/config.md +++ b/docs/config.md @@ -1,6 +1,6 @@ # Configuration -These are the config settings available to jj/Jujutsu. +These are the config settings available to `jj`/Jujutsu. ## Config files and TOML @@ -642,7 +642,7 @@ Obviously, you would only set one line, don't copy them all in! ## Editing diffs The `ui.diff-editor` setting affects the default tool used for editing diffs -(e.g. `jj split`, `jj squash -i`). If it is not set, the special value +(e.g. `jj split`, `jj squash -i`). If it is not set, the special value `:builtin` is used. It launches a built-in TUI tool (known as [scm-diff-editor]) to edit the diff in your terminal. @@ -767,7 +767,7 @@ same as the contents of `$right`. ### `JJ-INSTRUCTIONS` -When editing a diff, jj will include a synthetic file called `JJ-INSTRUCTIONS` +When editing a diff, `jj` will include a synthetic file called `JJ-INSTRUCTIONS` in the diff with instructions on how to edit the diff. Any changes you make to this file will be ignored. To suppress the creation of this file, set `ui.diff-instructions = false`. @@ -1004,7 +1004,7 @@ backends.ssh.allowed-signers = "/path/to/allowed-signers" By default, if a single remote exists it is used for `jj git fetch` and `jj git push`; however if multiple remotes exist, the default remote is assumed to be -named `"origin"`, just like in Git. Sometimes this is undesirable, e.g. when you +named "origin", just like in Git. Sometimes this is undesirable, e.g. when you want to fetch from a different remote than you push to, such as a GitHub fork. To change this behavior, you can modify the [repository @@ -1116,7 +1116,7 @@ To configure the Watchman filesystem monitor, set `core.fsmonitor = "watchman"`. Ensure that you have [installed the Watchman executable on your system](https://facebook.github.io/watchman/docs/install). -You can configure `jj` to use watchman triggers to automatically create +You can configure `jj` to use Watchman triggers to automatically create snapshots on filesystem changes by setting `core.watchman.register_snapshot_trigger = true`. diff --git a/docs/contributing.md b/docs/contributing.md index 8872606b0be..bec076800b7 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -39,7 +39,7 @@ 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 start the commit message with `: ` and don't use +message. We start the commit message with `:` and don't use [conventional commits](https://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: ` or `conflicts: `. We don't @@ -364,7 +364,7 @@ Windows, you'll need to understand and adapt the shell script): cloned from your fork of `jj` (e.g. `github.com/jjfan/jj`). You can also use a pure Git repo if you prefer. -2. Make sure `github.com/jjfan/jj` includes the `gh-pages` bookmark of the jj repo +2. Make sure `github.com/jjfan/jj` includes the `gh-pages` bookmark of the `jj` repo and run `git fetch origin gh-pages`. 3. Go to the GitHub repository settings, enable GitHub Pages, and configure them @@ -430,7 +430,7 @@ you can submit a PR based on the `gh-pages` bookmark of ## Modifying protobuffers (this is not common) -Occasionally, you may need to change the `.proto` files that define jj's data +Occasionally, you may need to change the `.proto` files that define `jj`'s data storage format. In this case, you will need to add a few steps to the above workflow. diff --git a/docs/git-compatibility.md b/docs/git-compatibility.md index a1b5c51cf5b..258e14fd879 100644 --- a/docs/git-compatibility.md +++ b/docs/git-compatibility.md @@ -156,7 +156,7 @@ repos may require you to deal with more involved Jujutsu and Git concepts. as Git represents them, unfinished `git rebase` states, as well as other less common states a Git repository can be in. -* Colocated repositories are less resilient to +* Co-located repositories are less resilient to [concurrency](technical/concurrency.md#syncing-with-rsync-nfs-dropbox-etc) issues if you share the repo using an NFS filesystem or Dropbox. In general, such use of Jujutsu is not currently thoroughly tested. diff --git a/docs/glossary.md b/docs/glossary.md index dc9eae94850..997a65d5b46 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -14,7 +14,7 @@ A backend is an implementation of the storage layer. There are currently two builtin commit backends: the Git backend and the native backend. The Git backend stores commits in a Git repository. The native backend is used for testing purposes only. Alternative backends could be used, for example, if somebody -wanted to use jj with a humongous monorepo (as Google does). +wanted to use `jj` with a humongous monorepo (as Google does). There are also pluggable backends for storing other information than commits, such as the "operation store backend" for storing @@ -141,7 +141,7 @@ The operation log is the [operation](#operation) objects, much in the same way that commits form a DAG, which is sometimes called the "commit history". When operations happen in sequence, they form a single line in the graph. Operations that happen -concurrently from jj's perspective result in forks and merges in the DAG. +concurrently from `jj`'s perspective result in forks and merges in the DAG. ## Repository @@ -154,7 +154,7 @@ TODO ## Revision -A synonym for [Commit](#commit). +A synonym for [commit](#commit). ## Revset diff --git a/docs/revsets.md b/docs/revsets.md index 57f1386cc93..d2b1ebd8bdf 100644 --- a/docs/revsets.md +++ b/docs/revsets.md @@ -533,7 +533,7 @@ Show commits not on any remote bookmark: jj log -r 'remote_bookmarks()..' ``` -Show commits not on `origin` (if you have other remotes like `fork`): +Show commits not on "origin" (if you have other remotes like "fork"): ```shell jj log -r 'remote_bookmarks(remote=origin)..' diff --git a/docs/sapling-comparison.md b/docs/sapling-comparison.md index cf4ba27c986..939d6ff6d85 100644 --- a/docs/sapling-comparison.md +++ b/docs/sapling-comparison.md @@ -2,10 +2,10 @@ ## Introduction -This document attempts to describe how jj is different +This document attempts to describe how `jj` is different from [Sapling](https://sapling-scm.com). Sapling is a VCS developed by Meta. It -was announced about 3 years after development started on jj. It is a heavily -modified fork of [Mercurial](https://www.mercurial-scm.org/). Because jj has +was announced about 3 years after development started on `jj`. It is a heavily +modified fork of [Mercurial](https://www.mercurial-scm.org/). Because `jj` has copied many ideas from Mercurial, there are many similarities between the two tools, such as: @@ -18,11 +18,11 @@ tools, such as: ## Differences -Here is a list of some differences between jj and Sapling. +Here is a list of some differences between `jj` and Sapling. * **Working copy:** When using Sapling (like most VCSs), the user explicitly tells the tool when to create a commit and which files to - include. When using jj, the working copy + include. When using `jj`, the working copy is [automatically snapshotted by every command](working-copy.md). New files are automatically tracked and deleted files are automatically untracked. This has several advantages: @@ -34,40 +34,40 @@ Here is a list of some differences between jj and Sapling. other commit. * **Conflicts:** Like most VCSs, Sapling requires the user to - resolve conflicts before committing. jj lets + resolve conflicts before committing. `jj` lets you [commit conflicts](conflicts.md). Note that it's a representation of the conflict that's committed, not conflict markers (`<<<<<<<` etc.). This also has several advantages: * Merge conflicts won't prevent you from checking out another commit. * You can resolve the conflicts when you feel like it. - * Rebasing descendants always succeeds. Like jj, Sapling automatically + * Rebasing descendants always succeeds. Like `jj`, Sapling automatically rebases, but it will fail if there are conflicts. * Merge commits can be rebased correctly (Sapling sometimes fails). * You can rebase conflicts and conflict resolutions. -* **Undo:** jj's undo is powered by [the operation log](operation-log.md), which +* **Undo:** `jj`'s undo is powered by [the operation log](operation-log.md), which records how the repo has changed over time. Sapling has a similar feature with its [MetaLog](https://sapling-scm.com/docs/internals/metalog). - They seem to provide similar functionality, but jj also exposes the log to the + They seem to provide similar functionality, but `jj` also exposes the log to the user via `jj op log`, so you can tell how far back you want to go back. Sapling has `sl debugmetalog`, but that seems to show the history of a single - commit, not the whole repo's history. Thanks to jj snapshotting the working + commit, not the whole repo's history. Thanks to `jj` snapshotting the working copy, it's possible to undo changes to the working copy. For example, if you `jj undo` a ` jj commit`, `jj diff` will show the same changes as before `jj commit`, but if you `sl undo` a `sl commit`, the working copy will be clean. * **Git interop:** Sapling supports cloning, pushing, and pulling from a remote - Git repo. jj also does, and it also supports sharing a working copy with a Git + Git repo. `jj` also does, and it also supports sharing a working copy with a Git repo, so you can use `jj` and `git` interchangeably in the same repo. * **Polish:** Sapling is much more polished and feature-complete. For example, - jj has no `blame/annotate` or `bisect` commands, and also no copy/rename + `jj` has no `blame/annotate` or `bisect` commands, and also no copy/rename support. Sapling also has very nice web UI called [Interactive Smartlog](https://sapling-scm.com/docs/addons/isl), which lets you drag and drop commits to rebase them, among other things. * **Forge workflow:** Sapling has `sl pr submit --stack`, which lets you push a stack of commits as separate GitHub PRs, including setting the base - branch. It only supports GitHub. jj doesn't have any direct integration with + branch. It only supports GitHub. `jj` doesn't have any direct integration with GitHub or any other forge. However, it has `jj git push --change` for automatically creating branches for specified commits. You have to specify each commit you want to create a branch for by using diff --git a/docs/templates.md b/docs/templates.md index 58484135fd0..ed0ea1c474d 100644 --- a/docs/templates.md +++ b/docs/templates.md @@ -302,7 +302,7 @@ This type cannot be printed. The following methods are defined. The default templates and aliases() are defined in the `[templates]` and `[template-aliases]` sections of the config respectively. The exact definitions -can be seen in the `cli/src/config/templates.toml` file in jj's source tree. +can be seen in the `cli/src/config/templates.toml` file in `jj`'s source tree.