diff --git a/docs/git-comparison.md b/docs/git-comparison.md index c4f804a05..2ddfa73da 100644 --- a/docs/git-comparison.md +++ b/docs/git-comparison.md @@ -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 ` will move the diff from that revision into its parent. diff --git a/docs/related-work.md b/docs/related-work.md index be1dc7c0c..674e24d34 100644 --- a/docs/related-work.md +++ b/docs/related-work.md @@ -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. diff --git a/docs/revsets.md b/docs/revsets.md index 595ead570..62c365a1a 100644 --- a/docs/revsets.md +++ b/docs/revsets.md @@ -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 -`@` to refer to the working copy commit in another workspace. +`@` 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 @- ``` diff --git a/docs/tutorial.md b/docs/tutorial.md index dadd8d151..67b08308e 100644 --- a/docs/tutorial.md +++ b/docs/tutorial.md @@ -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 diff --git a/docs/working-copy.md b/docs/working-copy.md index 1288a89aa..4da8ad693 100644 --- a/docs/working-copy.md +++ b/docs/working-copy.md @@ -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.