reorg
authorJoey Hess <joeyh@joeyh.name>
Thu, 10 Dec 2020 15:25:02 +0000 (11:25 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 10 Dec 2020 15:25:02 +0000 (11:25 -0400)
doc/git-annex.mdwn

index f83398997eadb53df9e569d4415eeb39f32be906..9fba53ecb341f34a4a2899fe919fc082fe849779 100644 (file)
@@ -1405,12 +1405,6 @@ Remotes are configured using these settings in `.git/config`.
   When this happens, the transfer will be considered to have failed, so
   settings like annex.retry will control what it does next.
 
-  This is not enabled by default, because it can make git-annex use
-  more resources. In order to cancel stalls, git-annex has to run
-  transfers in separate processes (one per concurrent job). So it
-  may need to open more connections to a remote than usual, or
-  the communication with those processes may make it a bit slower.
-
   The value specifies how much data git-annex should expect to see
   flowing, minimum, when it's not stalled, over a given period of time.
   The format is "$amount/$timeperiod". 
@@ -1423,6 +1417,12 @@ Remotes are configured using these settings in `.git/config`.
   stuck for a long time, you could use:
   `git config remote.usbdrive.annex-stalldetection "1MB/1m"`
 
+  This is not enabled by default, because it can make git-annex use
+  more resources. To be able to cancel stalls, git-annex has to run
+  transfers in separate processes (one per concurrent job). So it
+  may need to open more connections to a remote than usual, or
+  the communication with those processes may make it a bit slower.
+
 * `remote.<name>.annex-checkuuid`
 
   This only affects remotes that have their url pointing to a directory on