mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2025-01-12 07:14:38 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 13

docs: hyphenate "working-copy" when used as a compound modifier

Browse source
This commit is contained in:
Martin von Zweigbergk 2022-08-25 16:34:18 -07:00 committed by Martin von Zweigbergk
parent 16cb7fdee8
commit b8f59f419c
5 changed files with 18 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/git-comparison.md
View file

@ -66,7 +66,7 @@ commit only part of the working copy. However, Jujutsu provides commands for
more directly achieving most use cases you're used to using Git's index for. For more directly achieving most use cases you're used to using Git's index for. For
example, to create a commit from part of the changes in the working copy, you example, to create a commit from part of the changes in the working copy, you
might be used to using `git add -p; git commit`. With Jujutsu, you'd instead might be used to using `git add -p; git commit`. With Jujutsu, you'd instead
use `jj split` to split the working copy commit into two commits. To add more use `jj split` to split the working-copy commit into two commits. To add more
changes into the parent commit, which you might normally use changes into the parent commit, which you might normally use
`git add -p; git commit --amend` for, you can instead use `jj squash -i` to `git add -p; git commit --amend` for, you can instead use `jj squash -i` to
choose which changes to move into the parent commit. choose which changes to move into the parent commit.
@ -74,7 +74,7 @@ choose which changes to move into the parent commit.
## Command equivalence table ## Command equivalence table
Note that all `jj` commands can be run on any commit (not just the working copy Note that all `jj` commands can be run on any commit (not just the working-copy
commit), but that's left out of the table to keep it simple. For example, commit), but that's left out of the table to keep it simple. For example,
`jj squash/amend -r <revision>` will move the diff from that revision into its `jj squash/amend -r <revision>` will move the diff from that revision into its
parent. parent.

2
docs/related-work.md
View file

@ -11,7 +11,7 @@ Similar tools:
[GitUpKit library](https://github.com/git-up/GitUp#gitupkit). [GitUpKit library](https://github.com/git-up/GitUp#gitupkit).
* [Gitless](https://gitless.com/): Another attempt at providing a simpler * [Gitless](https://gitless.com/): Another attempt at providing a simpler
interface for Git. Like Jujutsu, does not have an "index"/"staging area" interface for Git. Like Jujutsu, does not have an "index"/"staging area"
concept. Also doesn't move the working copy changes between branches (which concept. Also doesn't move the working-copy changes between branches (which
we do simply as a consequence of making the working copy a commit). we do simply as a consequence of making the working copy a commit).
* [Pijul](https://pijul.org/): Architecturally quite different from Jujutsu, * [Pijul](https://pijul.org/): Architecturally quite different from Jujutsu,
but its "first-class conflicts" feature seems quite similar to ours. but its "first-class conflicts" feature seems quite similar to ours.

4
docs/revsets.md
View file

@ -23,7 +23,7 @@ The symbol `root` refers to the virtual commit that is the oldest ancestor of
all other commits. all other commits.
The symbol `@` refers to the working copy commit in the current workspace. Use The symbol `@` refers to the working copy commit in the current workspace. Use
`<workspace name>@` to refer to the working copy commit in another workspace. `<workspace name>@` to refer to the working-copy commit in another workspace.
A full commit ID refers to a single commit. A unique prefix of the full commit A full commit ID refers to a single commit. A unique prefix of the full commit
ID can also be used. It is an error to use a non-unique prefix. ID can also be used. It is an error to use a non-unique prefix.
@ -116,7 +116,7 @@ revsets (expressions) as arguments.
## Examples ## Examples
Show the parent(s) of the working copy commit (like `git log -1 HEAD`): Show the parent(s) of the working-copy commit (like `git log -1 HEAD`):
``` ```
jj log -r @- jj log -r @-
``` ```

18
docs/tutorial.md
View file

@ -43,10 +43,10 @@ The working copy is clean
``` ```
You might have noticed that even though we asked to check out some commit You might have noticed that even though we asked to check out some commit
(`080a9b37ff7e`), our working copy commit ended being another commit (`080a9b37ff7e`), our working-copy commit ended being another commit
(`608c179a60df`). That is because `jj co` (short for `jj checkout`) creates a (`608c179a60df`). That is because `jj co` (short for `jj checkout`) creates a
new commit on top of the commit you asked it to check out. The new commit is for new commit on top of the commit you asked it to check out. The new commit is for
the working copy changes. (There's some more nuance to this. We'll go through the working-copy changes. (There's some more nuance to this. We'll go through
that in a bit.) that in a bit.)
## Creating our first change ## Creating our first change
@ -97,13 +97,13 @@ Jujutsu's diff format currently defaults to inline coloring of the diff (like
`git diff --color-words`), so we used `--git` above to make the diff visible in `git diff --color-words`), so we used `--git` above to make the diff visible in
this doc. this doc.
As you may have noticed, the working copy commit's ID changed both when we As you may have noticed, the working-copy commit's ID changed both when we
edited the description and when we edited the README. However, the parent commit edited the description and when we edited the README. However, the parent commit
stayed the same. Each change to the working copy commit amends the previous stayed the same. Each change to the working-copy commit amends the previous
version. So how do we tell Jujutsu that we are done amending the working copy version. So how do we tell Jujutsu that we are done amending the working-copy
commit? The answer is that we need to "close" the commit. When we close a commit? The answer is that we need to "close" the commit. When we close a
commit, we indicate that we're done making changes to the commit. As described commit, we indicate that we're done making changes to the commit. As described
earlier, when we check out a commit, a new working copy commit is created on earlier, when we check out a commit, a new working-copy commit is created on
top. However, that is only true for closed commits. If the commit is open, then top. However, that is only true for closed commits. If the commit is open, then
that commit itself will be checked out instead. that commit itself will be checked out instead.
@ -123,7 +123,7 @@ indicates a closed commit.
If we later realize that we want to make further changes, we can make them If we later realize that we want to make further changes, we can make them
in the working copy and then run `jj squash`. That command squashes the changes in the working copy and then run `jj squash`. That command squashes the changes
from a given commit into its parent commit. Like most commands, it acts on the from a given commit into its parent commit. Like most commands, it acts on the
working copy commit by default. working-copy commit by default.
## The log command, "revsets", and aliases ## The log command, "revsets", and aliases
@ -139,7 +139,7 @@ o 080a9b37ff7e 6a91b4ba16c7 martinvonz@google.com 2021-05-23 22:08:37.000 -07:00
~ cli: make `jj st` show parent commit before working copy commit ~ cli: make `jj st` show parent commit before working copy commit
``` ```
The `@` indicates the working copy commit. The first hash on a line is the The `@` indicates the working-copy commit. The first hash on a line is the
commit ID. The second hash is a "change ID", which is an ID that follows the commit ID. The second hash is a "change ID", which is an ID that follows the
commit as it's rewritten (similar to Gerrit's Change-Id). You can give either commit as it's rewritten (similar to Gerrit's Change-Id). You can give either
hash to commands that take revisions as arguments. We will generally prefer hash to commands that take revisions as arguments. We will generally prefer
@ -150,7 +150,7 @@ context. The `~` indicates that the commit has parents that are not included
in the graph. We can use the `-r` flag to select a different set of revisions we in the graph. We can use the `-r` flag to select a different set of revisions we
want to list. The flag accepts a ["revset"](revsets.md), which is an expression want to list. The flag accepts a ["revset"](revsets.md), which is an expression
in a simple language for specifying revisions. For example, `@` refers to the in a simple language for specifying revisions. For example, `@` refers to the
working copy commit, `root` refers to the root commit, `branches()` refers to working-copy commit, `root` refers to the root commit, `branches()` refers to
all commits pointed to by branches. We can combine expressions with `|` for all commits pointed to by branches. We can combine expressions with `|` for
union, `&` for intersection and `~` for difference. For example: union, `&` for intersection and `~` for difference. For example:
```shell script ```shell script

8
docs/working-copy.md
View file

@ -8,9 +8,9 @@ interact with them. It also where files are read from in order to create new
commits (though there are many other ways of creating new commits). commits (though there are many other ways of creating new commits).
Unlike most other VCSs, Jujutsu will automatically create commits from the Unlike most other VCSs, Jujutsu will automatically create commits from the
working copy contents when they have changed. Most `jj` commands you run will working-copy contents when they have changed. Most `jj` commands you run will
commit the working copy changes if they have changed. The resulting revision commit the working-copy changes if they have changed. The resulting revision
will replace the previous working copy revision. will replace the previous working-copy revision.
Also unlike most other VCSs, added files are implicitly tracked. That means that Also unlike most other VCSs, added files are implicitly tracked. That means that
if you add a new file to the working copy, it will be automatically committed if you add a new file to the working copy, it will be automatically committed
@ -51,7 +51,7 @@ You can even resolve part of a conflict by updating the different parts of the
conflict marker. conflict marker.
If the commit with conflicts was closed, your conflict resolution would be in If the commit with conflicts was closed, your conflict resolution would be in
the working copy commit. Once you have resolved the conflicts, you would then the working-copy commit. Once you have resolved the conflicts, you would then
typically use `jj squash` to move the conflict resolutions into the conflicted typically use `jj squash` to move the conflict resolutions into the conflicted
commit. commit.