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

readme: fix two more little typos

Browse source
This commit is contained in:
Martin von Zweigbergk 2020-12-18 15:46:49 -08:00
parent 9f4c3bab5e
commit 2d9aa08334
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -169,14 +169,14 @@ problem, we get some very useful UX features. Many UX features come from mapping
commands that work on the commit graph onto the operation graph. For example, if commands that work on the commit graph onto the operation graph. For example, if
you map `git revert`/`hg backout` onto the operation graph, you get an operation you map `git revert`/`hg backout` onto the operation graph, you get an operation
that undoes a previous operation (called `jj op undo`). Note that any operation that undoes a previous operation (called `jj op undo`). Note that any operation
can be undo, not just the latest one. If you map `git restore`/`hg revert` onto can be undone, not just the latest one. If you map `git restore`/`hg revert`
the operation graph, you get an operation that rewinds the repo state to an onto the operation graph, you get an operation that rewinds the repo state to an
earlier point (called `jj op restore`). earlier point (called `jj op restore`).
You can also see what the repo looked like at an earlier point with `jj You can also see what the repo looked like at an earlier point with `jj
--at-op=<operation id> log`. As mentioned earlier, the checkout is also part of --at-op=<operation id> log`. As mentioned earlier, the checkout is also part of
the view, so that command will show you where the working copy was at that the view, so that command will show you where the working copy was at that
operation. If you do `jj restore -o <operation id>`, it will also update the operation. If you do `jj op restore -o <operation id>`, it will also update the
working copy accordingly. This is actually how the working copy is always working copy accordingly. This is actually how the working copy is always
updated: we first commit a transaction with a pointer to the new checkout and updated: we first commit a transaction with a pointer to the new checkout and
then the working copy is updated to reflect that. then the working copy is updated to reflect that.