From 377741c5c662e2061949aa3a119b2ff7697a7fb5 Mon Sep 17 00:00:00 2001 From: Martin von Zweigbergk Date: Fri, 28 Jan 2022 22:36:56 -0800 Subject: [PATCH] docs: make "features" in readme a heading with sub-headings instead of bullets The list of features outgrew the bullet form a long time ago... --- README.md | 106 +++++++++++++++++++++++++++--------------------------- 1 file changed, 52 insertions(+), 54 deletions(-) diff --git a/README.md b/README.md index d81053357..a3f33cc52 100644 --- a/README.md +++ b/README.md @@ -27,75 +27,73 @@ The command-line tool is called `jj` for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj". -Features: +## Features - * **Compatible with Git** +### Compatible with Git - Jujutsu has two backends. One of them is a Git backend (the other is a - native one). This lets you use Jujutsu as an alternative interface to Git. - The commits you create will look like regular Git commits. You can always - switch back to Git. - - - - +Jujutsu has two backends. One of them is a Git backend (the other is a native +one). This lets you use Jujutsu as an alternative interface to Git. The commits +you create will look like regular Git commits. You can always switch back to +Git. - * **The working copy is automatically committed** + + + - Most Jujutsu commands automatically commit the working copy. This leads to a - simpler and more powerful interface, since all commands work the same way on - the working copy or any other commit. It also means that you can always check - out a different commit without first explicitly committing the working copy - changes (you can even check out a different commit while resolving merge - conflicts). +### The working copy is automatically committed - - - +Most Jujutsu commands automatically commit the working copy. This leads to a +simpler and more powerful interface, since all commands work the same way on the +working copy or any other commit. It also means that you can always check out a +different commit without first explicitly committing the working copy changes +(you can even check out a different commit while resolving merge conflicts). - * **Operations update the repo first, then possibly the working copy** + + + - The working copy is only updated at the end of an operation, after all other - changes have already been recorded. This means that you can run any command - (such as `jj rebase`) even if the working copy is dirty. +### Operations update the repo first, then possibly the working copy - * **Entire repo is under version control** +The working copy is only updated at the end of an operation, after all other +changes have already been recorded. This means that you can run any command +(such as `jj rebase`) even if the working copy is dirty. - All operations you perform in the repo are recorded, along with a snapshot of - the repo state after the operation. This means that you can easily revert to - an earlier repo state, or to simply undo a particular operation (which does - not necessarily have to be the most recent operation). +### Entire repo is under version control - - - +All operations you perform in the repo are recorded, along with a snapshot of +the repo state after the operation. This means that you can easily revert to an +earlier repo state, or to simply undo a particular operation (which does not +necessarily have to be the most recent operation). - * **Conflicts can be recorded in commits** + + + - If an operation results in conflicts, information about those conflicts will - be recorded in the commit(s). The operation will succeed. You can then - resolve the conflicts later. One consequence of this design is that there's - no need to continue interrupted operations. Instead, you get a single - workflow for resolving conflicts, regardless of which command caused them. - This design also lets Jujutsu rebase merge commits correctly (unlike both Git - and Mercurial). +### Conflicts can be recorded in commits - Basic conflict resolution: - - - - Juggling conflicts: - - - +If an operation results in conflicts, information about those conflicts will be +recorded in the commit(s). The operation will succeed. You can then resolve the +conflicts later. One consequence of this design is that there's no need to +continue interrupted operations. Instead, you get a single workflow for +resolving conflicts, regardless of which command caused them. This design also +lets Jujutsu rebase merge commits correctly (unlike both Git and Mercurial). - * **Automatic rebase** +Basic conflict resolution: + + + - Whenever you modify a commit, any descendants of the old commit will be - rebased onto the new commit. Thanks to the conflict design described above, - that can be done even if there are conflicts. Branches pointing to rebased - commits will be updated. So will the working copy if it points to a rebased - commit. +Juggling conflicts: + + + + +### Automatic rebase + +Whenever you modify a commit, any descendants of the old commit will be rebased +onto the new commit. Thanks to the conflict design described above, that can be +done even if there are conflicts. Branches pointing to rebased commits will be +updated. So will the working copy if it points to a rebased commit. ## Status ##