chiark / gitweb /
README.md: Reorder options to put most usual first
authorIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 21 Jun 2020 13:34:01 +0000 (14:34 +0100)
committerIan Jackson <ijackson@chiark.greenend.org.uk>
Sun, 21 Jun 2020 13:34:20 +0000 (14:34 +0100)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
README.md

index c22d08d54c230968215bde41e037725846097592..25c0e8c26546a63f8ad8215a25f3a195fbb7bec2 100644 (file)
--- a/README.md
+++ b/README.md
@@ -261,22 +261,27 @@ Options
     then in the builtin arch alias list.  The builtin list is
     equivalent to: `[arch]` `RPI='arm-unknown-linux-gnueabihf'`.
 
-  * <a name="s_subcommand">`-s<subcommand>`</a>
+  * `-o` | `--online` | `-O` | `--offline`
 
-    Behave as if the build command were `cargo <subcommand>`.
-    This influences the logic which tries to determine which
-    options to pass to cargo, whether cargo needs to be online, and
-    whether cargo might want to update `Cargo.lock`.
+    Whether to allow cargo to make network access.  nailing-cargo
+    always passes `--offline` to cargo, unless `--online` is in
+    force.  The default value depends on the configuration and the
+    cargo subcommand - see [`[misc]` `online`](#misc_online),
+    under Configuration.
 
-    nailing-cargo knows about `update`, `generate-lockfile` and
-    `fetch`; all other subcommands are (silently) treated the same way
-    as `build` (ie, no subcommand properties).  See
-    [`--subcommand-props`](#subcommand_props) for more detail about how the
-    subcommand affects nailing-cargo's behaviour.
+  * `-u` | `--cargo-lock-update` | `-U` | `--no-cargo-lock-update`
 
-    The default is to use the cargo subcommand found from parsing
-    nailing-cargo's command line.  NB: `-s` does not affect
-    which build command (and which cargo subcommand) is actually run.
+    Enables, or disables, the dance to allow `Cargo.lock` (or
+    alternative) to be updated in the source directory.
+
+    With this dance enabled the `Cargo.lock` and `Cargo.toml` are
+    copied to the build directory along with a skeleton just big
+    enough to fool cargo.  After cargo has run, the resulting
+    `Cargo.lock` is copied back to the source tree.
+
+    This makes no sense with in-tree builds.
+
+    Default is no update unless the cargo subcommand will want it.
 
   * `-c` | `-C`
 
@@ -296,27 +301,22 @@ Options
     rather than a non-cargo build command (usage 3).  `-C` and `-c`
     do not affect the parsing of nailing-cargo's command line.
 
-  * `-o` | `--online` | `-O` | `--offline`
-
-    Whether to allow cargo to make network access.  nailing-cargo
-    always passes `--offline` to cargo, unless `--online` is in
-    force.  The default value depends on the configuration and the
-    cargo subcommand - see [`[misc]` `online`](#misc_online),
-    under Configuration.
-
-  * `-u` | `--cargo-lock-update` | `-U` | `--no-cargo-lock-update`
-
-    Enables, or disables, the dance to allow `Cargo.lock` (or
-    alternative) to be updated in the source directory.
+  * <a name="s_subcommand">`-s<subcommand>`</a>
 
-    With this dance enabled the `Cargo.lock` and `Cargo.toml` are
-    copied to the build directory along with a skeleton just big
-    enough to fool cargo.  After cargo has run, the resulting
-    `Cargo.lock` is copied back to the source tree.
+    Behave as if the build command were `cargo <subcommand>`.
+    This influences the logic which tries to determine which
+    options to pass to cargo, whether cargo needs to be online, and
+    whether cargo might want to update `Cargo.lock`.
 
-    This makes no sense with in-tree builds.
+    nailing-cargo knows about `update`, `generate-lockfile` and
+    `fetch`; all other subcommands are (silently) treated the same way
+    as `build` (ie, no subcommand properties).  See
+    [`--subcommand-props`](#subcommand_props) for more detail about how the
+    subcommand affects nailing-cargo's behaviour.
 
-    Default is no update unless the cargo subcommand will want it.
+    The default is to use the cargo subcommand found from parsing
+    nailing-cargo's command line.  NB: `-s` does not affect
+    which build command (and which cargo subcommand) is actually run.
 
   * <a name="subcommand_props">`--subcommand-props=<prop>,...`</a>