Merge pull request #1140 from datalad-handbook/polish

Simplify section cross-refs

docs/basics/101-115-symlinks.rst

@@ -168,8 +168,8 @@ work with the paths in the object tree than you or any other human are.
 Lastly, understanding that annexed files in your dataset are symlinked
 will be helpful to understand how common file system operations such as
 moving, renaming, or copying content translate to dataset modifications
-in certain situations. Later in this book we will have a section on how
-to manage the file system in a DataLad dataset (:ref:`file system`).
+in certain situations. Later in this book, the section :ref:`file system`
+will take a closer look at that.
 
 .. index::
    pair: key; git-annex concept
@@ -227,7 +227,7 @@ to manage the file system in a DataLad dataset (:ref:`file system`).
    consisting of two letters each.
    These two letters are derived from the md5sum of the key, and their sole purpose to exist is to avoid issues with too many files in one directory (which is a situation that certain file systems have problems with).
    The next subdirectory in the symlink helps to prevent accidental deletions and changes, as it does not have write :term:`permissions`, so that users cannot modify any of its underlying contents.
-   This is the reason that annexed files need to be unlocked prior to modifications, and this information will be helpful to understand some file system management operations such as removing files or datasets (see section :ref:`file system`).
+   This is the reason that annexed files need to be unlocked prior to modifications, and this information will be helpful to understand some file system management operations such as removing files or datasets. Section :ref:`file system` takes a look at that.
 
    The next part of the symlink contains the actual hash.
    There are different hash functions available.

docs/basics/101-116-sharelocal.rst

@@ -49,8 +49,8 @@ But as we cannot easily simulate a second user in this handbook,
 for now, you will have to share your dataset with yourself.
 This endeavor serves several purposes: For one, you will experience a very easy
 way of sharing a dataset. Secondly, it will show you
-how a dataset can be obtained from a path (instead of a URL as shown in the section
-:ref:`installds`). Thirdly, ``DataLad-101`` is a dataset that can
+how a dataset can be obtained from a path, instead of a URL as shown in section
+:ref:`installds`. Thirdly, ``DataLad-101`` is a dataset that can
 showcase many different properties of a dataset already, but it will
 be an additional learning experience to see how the different parts
 of the dataset -- text files, larger files, subdatasets,

docs/basics/101-139-gitlfs.rst

@@ -56,7 +56,7 @@ Alternatively, to make publication even easier for you, the dataset provider, yo
    # afterwards, only datalad push is needed to publish dataset contents and history
    $ datalad push --to github
 
-Consumers of your dataset should be able to retrieve files right after cloning the dataset without a ``siblings enable`` command (as shown in the section :ref:`dropbox`), because of the ``autoenable=true`` configuration for the special remote.
+Consumers of your dataset should be able to retrieve files right after cloning the dataset without a ``siblings enable`` command, as shown in section :ref:`dropbox`, because of the ``autoenable=true`` configuration for the special remote.
 
 .. index::
    pair: drop (LFS); with DataLad

docs/basics/topic/adjustedmode-nosymlinks.rst

@@ -4,7 +4,7 @@ While git-annex on Unix-based file operating systems stores data in the annex an
 
 **Why is that?**
 Data *needs* to be in the annex for version control and transport logistics -- the annex is able to store all previous versions of the data, and manage the transport to other storage locations if you want to publish your dataset.
-But as the :ref:`Findoutmore in this section <fom-objecttree>` will show, the :term:`annex` is a non-human readable tree structure, and data thus also needs to exist in its original location.
+But as the :ref:`Findoutmore in this section <fom-objecttree>` shows, the :term:`annex` is a non-human readable tree structure, and data thus also needs to exist in its original location.
 Thus, it exists in both places: it has moved into the annex, and copied back into its original location.
 Once you edit an annexed file, the most recent version of the file is available in its original location, and past versions are stored and readily available in the annex.
 If you reset your dataset to a previous state (as is shown in the section :ref:`history`), the respective version of your data is taken from the annex and copied to replace the newer version, and vice versa.