mirrors/jj
1
0
Fork 1
mirror of https://github.com/martinvonz/jj.git synced 2024-12-24 20:54:15 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6

docs: change "current checkout" to "working-copy commit"

Browse source 
I think "the working-copy commit" is clearer.
This commit is contained in:
Martin von Zweigbergk 2022-09-18 14:46:12 -07:00 committed by Martin von Zweigbergk
parent 86f216541a
commit 6e23b5b052
4 changed files with 30 additions and 29 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
docs/git-compatibility.md
View file

@ -78,16 +78,16 @@ underlying Git repo will be inside of that directory (currently in
To create a Jujutsu repo backed by a Git repo you already have on disk, use To create a Jujutsu repo backed by a Git repo you already have on disk, use
`jj init --git-repo=<path to Git repo> <name>`. The repo will work similar to a `jj init --git-repo=<path to Git repo> <name>`. The repo will work similar to a
[Git worktree](https://git-scm.com/docs/git-worktree), meaning that the working [Git worktree](https://git-scm.com/docs/git-worktree), meaning that the working
copies and the record of the current checkout will be separate, but the commits copies files and the record of the working-copy commit will be separate, but the
will be accessible in both repos. Use `jj git import` to update the Jujutsu repo commits will be accessible in both repos. Use `jj git import` to update the
with changes made in the Git repo. Use `jj git export` to update the Git repo Jujutsu repo with changes made in the Git repo. Use `jj git export` to update
with changes made in the Jujutsu repo. the Git repo with changes made in the Jujutsu repo.
If you create initialize the Jujutsu repo in the same working copy as the Git If you initialize the Jujutsu repo in the same working copy as the Git repo by
repo by running `jj init --git-repo=.`, then the import and export will happen running `jj init --git-repo=.`, then the import and export will happen
automatically on every command (because not doing that makes it very confusing automatically on every command (because not doing that makes it very confusing
when the current checkout has changed in Git but not in Jujutsu or vice versa). when the working copy has changed in Git but not in Jujutsu or vice versa). This
This mode is meant to make it easier to start using readonly `jj` commands in an mode is meant to make it easier to start using readonly `jj` commands in an
existing Git repo. You should then be able to switch to using mutating `jj` existing Git repo. You should then be able to switch to using mutating `jj`
commands and readonly Git commands. The mode is new and not tested much, and commands and readonly Git commands. The mode is new and not tested much, and
interleaving mutating `jj` and `git` commands might not work well (feel free interleaving mutating `jj` and `git` commands might not work well (feel free

11
docs/operation-log.md
View file

@ -8,9 +8,10 @@ You can see the log with `jj op log`. Each operation object contains a snapshot
of how the repo looked at the end of the operation. We call this snapshot a of how the repo looked at the end of the operation. We call this snapshot a
"view" object. The view contains information about where each branch, tag, and "view" object. The view contains information about where each branch, tag, and
Git ref (in Git-backed repos) pointed, as well as the set of heads in the repo, Git ref (in Git-backed repos) pointed, as well as the set of heads in the repo,
and the current checkout. The operation object also (in addition to the view) and the current working-copy commit. The operation object also (in addition to
contains pointers to the operation(s) immediately before it, as well as metadata the view) contains pointers to the operation(s) immediately before it, as well
about the operation, such as timestamps, username, hostname, description. as metadata about the operation, such as timestamps, username, hostname,
description.
The operation log allows you to undo an operation (`jj op undo`), which doesn't The operation log allows you to undo an operation (`jj op undo`), which doesn't
need to be the most recent one. It also lets you restore the entire repo to the need to be the most recent one. It also lets you restore the entire repo to the
@ -44,11 +45,11 @@ else's repo got into its current state.
When you use `--at-op`, the automatic snapshotting of the working copy will not When you use `--at-op`, the automatic snapshotting of the working copy will not
take place. When referring to a revision with the `@` symbol (as many commands take place. When referring to a revision with the `@` symbol (as many commands
do by default), that will resolve to the current checkout recorded in the do by default), that will resolve to the working-copy commit recorded in the
operation's view (which is actually how it always works -- it's just the operation's view (which is actually how it always works -- it's just the
snapshotting that's skipped with `--at-op`). snapshotting that's skipped with `--at-op`).
As a top-level option, `--at-op`, it can be passed to any command. However, you As a top-level option, `--at-op` can be passed to any command. However, you
will typically only want to run read-only commands. For example, `jj log`, will typically only want to run read-only commands. For example, `jj log`,
`jj st`, and `jj diff` all make sense. It's still possible to run e.g. `jj st`, and `jj diff` all make sense. It's still possible to run e.g.
`jj --at-op=<some operation ID> describe`. That's equivalent to having started `jj --at-op=<some operation ID> describe`. That's equivalent to having started

2
docs/technical/concurrency.md
View file

@ -55,7 +55,7 @@ what allows us to detect and merge concurrent operations.
The operation log is similar to a commit DAG (such as in Git), but each commit The operation log is similar to a commit DAG (such as in Git), but each commit
object is instead an "operation" and each tree object is instead a "view". The object is instead an "operation" and each tree object is instead a "view". The
view object contains the set of visible head commits, branches, tags, and the view object contains the set of visible head commits, branches, tags, and the
current checkout. The operation object contains a pointer to the view object working-copy commit. The operation object contains a pointer to the view object
(like how commit objects point to tree objects), pointers to parent operation(s) (like how commit objects point to tree objects), pointers to parent operation(s)
(like how commit objects point to parent commit(s)), and metadata about the (like how commit objects point to parent commit(s)), and metadata about the
operation. These types are defined [here](../../lib/protos/op_store.proto). The operation. These types are defined [here](../../lib/protos/op_store.proto). The

30
docs/working-copy.md
View file

@ -3,9 +3,9 @@
## Introduction ## Introduction
The working copy is where the current checkout's files are written so you can The working copy is where the current working-copy commit's files are written so
interact with them. It also where files are read from in order to create new you can interact with them. It also where files are read from in order to create
commits (though there are many other ways of creating new commits). new 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
@ -26,18 +26,18 @@ This section only applies if you have set `ui.enable-open-commits = true`
in your config. in your config.
As described in the introduction, Jujutsu automatically rewrites the current As described in the introduction, Jujutsu automatically rewrites the current
checkout with any changes from the working copy. That works well while you're working-copy commit with any changes from the working copy. That works well
developing that revision. On the other hand, if you check out some existing while you're developing that revision. On the other hand, if you check out some
revision, you generally don't want changes to the working copy to automatically existing revision, you generally don't want changes to the working copy to
rewrite that revision. Jujutsu has a concept of "open" and "closed" revisions to automatically rewrite that revision. Jujutsu has a concept of "open" and
solve this. When you check out a closed revision, Jujutsu will actually create a "closed" revisions to solve this. When you check out a closed revision, Jujutsu
new, *open* revision on top of it and check that out. The checked-out revision will actually create a new, *open* revision on top of it and check that out. The
is thus always open. When you are done making changes to the currently working-copy commit is thus always open. When you are done making changes to
checked-out revision, you close it by running `jj close`. That command then the current working-copy commit, you close it by running `jj close`. That
updates to the rewritten revision (as most `jj` commands do), and since the command then updates to the rewritten revision (as most `jj` commands do), and
rewritten revision is now closed, it creates a new open revision on top. If you since the rewritten revision is now closed, it creates a new open revision on
check out a closed revision and make changes on top of it that you want to go top. If you check out a closed revision and make changes on top of it that you
into the revision, use `jj squash`. want to go into the revision, use `jj squash`.
## Conflicts ## Conflicts