mirror of
https://github.com/martinvonz/jj.git
synced 2024-09-11 05:45:30 +03:00
README: rewrite sections about the working-copy commit and repo-first design
I tried to clarify the benefits of these two features (#1708).
This commit is contained in:
parent
dc98a56119
commit
033b287e54
25
README.md
25
README.md
@ -63,19 +63,26 @@ add functionality that cannot easily be added to the Git backend.
|
|||||||
|
|
||||||
### The working copy is automatically committed
|
### The working copy is automatically committed
|
||||||
|
|
||||||
Most Jujutsu commands automatically commit the working copy. This leads to a
|
Almost all Jujutsu commands automatically commit the working copy. That means
|
||||||
simpler and more powerful interface, since all commands work the same way on the
|
that commands never fail because the working copy is dirty (no "error: Your
|
||||||
working copy or any other commit. It also means that you can always check out a
|
local changes to the following files..."), and there is no need for `git stash`.
|
||||||
different commit without first explicitly committing the working copy changes
|
You also get an automatic backup of the working copy whenever you run a command.
|
||||||
(you can even check out a different commit while resolving merge conflicts).
|
Also, because the working copy is a commit, commands work the same way on the
|
||||||
|
working-copy commit as on any other commit, so you can set the commit message
|
||||||
|
before you're done with the changes.
|
||||||
|
|
||||||
<img src="demos/working_copy.png" />
|
<img src="demos/working_copy.png" />
|
||||||
|
|
||||||
### Operations update the repo first, then possibly the working copy
|
### The repo is the source of truth
|
||||||
|
|
||||||
The working copy is only updated at the end of an operation, after all other
|
With Jujutsu, the working copy plays a smaller role than with Git. Commands
|
||||||
changes have already been recorded. This means that you can run any command
|
snapshot the working copy before they start, then the update the repo, and then
|
||||||
(such as `jj rebase`) even if the working copy is dirty.
|
the working copy is updated (if the working-copy commit was modified). Almost
|
||||||
|
all commands (even checkout!) operate on the commits in the repo, leaving the
|
||||||
|
common functionality of snapshotting and updating of the working copy to
|
||||||
|
centralized code. For example, `jj restore` (similar to `git restore`) can
|
||||||
|
restore from any commit and into any commit, and `jj describe` can set the
|
||||||
|
commit message of any commit (defaults to the working-copy commit).
|
||||||
|
|
||||||
### Entire repo is under version control
|
### Entire repo is under version control
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user