mirror of
https://github.com/martinvonz/jj.git
synced 2024-12-23 20:43:56 +00:00
docs: hyphenate "working-copy" when used as a compound modifier
This commit is contained in:
parent
16cb7fdee8
commit
b8f59f419c
5 changed files with 18 additions and 18 deletions
|
@ -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
|
||||
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
|
||||
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
|
||||
`git add -p; git commit --amend` for, you can instead use `jj squash -i` to
|
||||
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
|
||||
|
||||
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,
|
||||
`jj squash/amend -r <revision>` will move the diff from that revision into its
|
||||
parent.
|
||||
|
|
|
@ -11,7 +11,7 @@ Similar tools:
|
|||
[GitUpKit library](https://github.com/git-up/GitUp#gitupkit).
|
||||
* [Gitless](https://gitless.com/): Another attempt at providing a simpler
|
||||
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).
|
||||
* [Pijul](https://pijul.org/): Architecturally quite different from Jujutsu,
|
||||
but its "first-class conflicts" feature seems quite similar to ours.
|
||||
|
|
|
@ -23,7 +23,7 @@ The symbol `root` refers to the virtual commit that is the oldest ancestor of
|
|||
all other commits.
|
||||
|
||||
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
|
||||
ID can also be used. It is an error to use a non-unique prefix.
|
||||
|
@ -116,7 +116,7 @@ revsets (expressions) as arguments.
|
|||
|
||||
## 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 @-
|
||||
```
|
||||
|
|
|
@ -43,10 +43,10 @@ The working copy is clean
|
|||
```
|
||||
|
||||
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
|
||||
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.)
|
||||
|
||||
## 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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
working copy commit by default.
|
||||
working-copy commit by default.
|
||||
|
||||
## 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
|
||||
```
|
||||
|
||||
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 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
|
||||
|
@ -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
|
||||
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
|
||||
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
|
||||
union, `&` for intersection and `~` for difference. For example:
|
||||
```shell script
|
||||
|
|
|
@ -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).
|
||||
|
||||
Unlike most other VCSs, Jujutsu will automatically create commits from the
|
||||
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
|
||||
will replace the previous working copy revision.
|
||||
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
|
||||
will replace the previous working-copy revision.
|
||||
|
||||
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
|
||||
|
@ -51,7 +51,7 @@ You can even resolve part of a conflict by updating the different parts of the
|
|||
conflict marker.
|
||||
|
||||
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
|
||||
commit.
|
||||
|
||||
|
|
Loading…
Reference in a new issue