Merge pull request #1243 from malikwirin/patch-1

Fix some typos

.gitignore

@@ -16,6 +16,7 @@ docs/_build
 build/
 
 venv/
+.venv/
 
 *.egg-info
 

.zenodo.json

@@ -269,6 +269,10 @@
       "affiliation": "Faculty of Psychology and Human Movement Science, University of Hamburg, Hamburg, Germany",
       "orcid": "0000-0001-8343-4362"
     },
+    {
+      "name": "Najhi, Abdel Malik",
+      "affiliation": "Kempten University of Applied Sciences, Kempten, Germany"
+    },
     {
       "name": "Hanke, Michael",
       "affiliation": "Institute of Neuroscience and Medicine, Brain & Behaviour (INM-7), Research Centre Jülich, Jülich, Germany and Institute of Systems Neuroscience, Medical Faculty, Heinrich Heine University Düsseldorf, Düsseldorf, Germany",

docs/basics/101-116-sharelocal.rst

@@ -283,7 +283,7 @@ Write this note in "your own" (the original) ``DataLad-101`` dataset, though!
    Note that subdatasets will not be installed by default, but are only
    registered in the superdataset -- you will have to do a
    "datalad get -n PATH/TO/SUBDATASET" to install the subdataset for file
-   availability meta data. The -n/--no-data options prevents that file
+   availability meta data. The -n/--no-data option prevents that file
    contents are also downloaded.
 
    Note that a recursive "datalad get" would install all further

docs/basics/101-121-siblings.rst

@@ -357,7 +357,7 @@ Create a note about this, and save it.
    Afterwards, a "datalad update --how merge -s name" will integrate the
    changes made to the sibling into the dataset. A safe step in between
    is to do a "datalad update -s name" and checkout the changes with
-   "git/datalad diff" to remotes/origin/main
+   "git/datalad diff" to remotes/origin/main.
 
    EOT
    $ datalad save -m "Add note on adding siblings"

docs/basics/101-123-config2.rst

@@ -158,11 +158,11 @@ This key is defined on a per subdataset basis, and if set to "``skip``", the giv
 If you are a maintainer of a superdataset with monstrous amounts of subdatasets, you can set this option and share it together with the dataset to prevent an accidental, large recursive installation in particularly deeply nested subdatasets.
 Below is a minimally functional example on how to apply the configuration and how it works:
 
-Let's create a dataset hierarchy to work with (note that we concatenate multiple commands into a single line using bash's "and" ``&&`` operator):
+Let's create a dataset hierarchy in a temporary location as an example to work with (note that we concatenate multiple commands into a single line using bash's "and" ``&&`` operator):
 
 .. code-block:: console
 
-    $ # create a superdataset with two subdatasets
+    $ # create a superdataset with two subdatasets in a temporary directory
     $ datalad create superds && datalad -C superds create -d . subds1 && datalad -C superds create -d . subds2
     create(ok): /tmp/superds (dataset)
     add(ok): subds1 (file)
@@ -204,7 +204,7 @@ Here is the directory structure:
 
 .. code-block:: console
 
-    $ cd ../ && tree
+    $ cd superds/ && tree
     .
     ├── subds1
     │   ├── subsubds1
@@ -464,7 +464,7 @@ Write a note about configurations in datasets into ``notes.txt``.
    take precedence over more global or hared configurations, and
    environment variables take precedence over configurations in files.
 
-   The git config --list --show-origin command is a useful tool to give
+   The "git config --list --show-origin" command is a useful tool to give
    an overview over existing configurations. Particularly important may
    be the .gitattributes file, in which one can set rules for git-annex
    about which files should be version-controlled with Git instead of