re-run -> rerun

docs/basics/101-109-rerun.rst

@@ -2,7 +2,7 @@
    pair: rerun; DataLad command
 .. _run2:
 
-DataLad, re-run!
+DataLad, rerun!
 ----------------
 
 So far, you created a ``.tsv`` file of all

docs/basics/101-115-symlinks.rst

@@ -5,7 +5,7 @@ Data integrity
 --------------
 
 So far, we mastered quite a number of challenges:
-Creating and populating a dataset with large and small files, modifying content and saving the changes to history, installing datasets, even as subdatasets within datasets, recording the impact of commands on a dataset with the run and re-run commands, and capturing plenty of :term:`provenance` on the way.
+Creating and populating a dataset with large and small files, modifying content and saving the changes to history, installing datasets, even as subdatasets within datasets, recording the impact of commands on a dataset with the run and rerun commands, and capturing plenty of :term:`provenance` on the way.
 We further noticed that when we modified content in ``notes.txt`` or ``list_titles.sh``, the modified content was in a *text file*.
 We learned that this precise type of file, in conjunction with the initial configuration template ``text2git`` we gave to :dlcmd:`create`, is meaningful:
 As the text file is stored in Git and not git-annex, no content unlocking is necessary.

docs/beyond_basics/101-171-enki.rst

@@ -191,9 +191,9 @@ This initial sketch serves to highlight key differences and adjustments due to t
    # job handler should clean up workspace
 
 Just like the general script from the last section, this script can be submitted to any job scheduler -- here with a subject ID as a ``$subid`` command line variable and a job ID as environment variable as identifiers for the fMRIprep run and branch names.
-At this point, the workflow misses a tweak that is necessary in fMRIprep to enable re-running computations  (the complete file is in :ref:`this Findoutmore <fom-enki>`.
+At this point, the workflow misses a tweak that is necessary in fMRIprep to enable rerunning computations  (the complete file is in :ref:`this Findoutmore <fom-enki>`.
 
-.. find-out-more:: Fine-tuning: Enable re-running
+.. find-out-more:: Fine-tuning: Enable rerunning
 
    If you want to make sure that your dataset is set up in a way that you have the ability to rerun a computation quickly, the following fMRIprep-specific consideration is important:
    If fMRIprep finds preexisting results, it will fail to run.

docs/beyond_basics/101-179-gitignore.rst

@@ -152,7 +152,7 @@ your dataset to be messy, if you want to be.
    subdirectories of your dataset. The rules in these nested ``.gitignore`` files only
    apply to the files under the directory where they are located.
 
-.. importantnote:: Implications of git-ignored outputs for re-running
+.. importantnote:: Implications of git-ignored outputs for rerunning
 
    Note one caveat: If a command creates an output that is git-ignored,
    (e.g. anything inside of ``tmp/`` in our dataset), a subsequent command

docs/usecases/reproducible_neuroimaging_analysis.rst

@@ -461,7 +461,7 @@ Since the state of the subdataset is exactly the state of the original
 Prior to archiving the results, we can go one step further and verify their
 computational reproducibility. DataLad's ``rerun`` command is
 capable of “replaying” any recorded command. The following command
-re-executes the FSL analysis by re-running everything since the dataset was
+re-executes the FSL analysis by rerunning everything since the dataset was
 tagged as ``ready4analysis``). It will record the recomputed results in a
 separate Git branch named ``verify``. Afterwards, we can automatically
 compare these new results to the original ones in the ``master`` branch. We

docs/usecases/reproducible_neuroimaging_analysis_simple.rst

@@ -164,10 +164,10 @@ All changes, including the command that caused them are on record:
 
    $ git show --stat
 
-DataLad has enough information stored to be able to re-run a command.
+DataLad has enough information stored to be able to rerun a command.
 
 On command exit, it will inspect the results and save them again, but only if they are different.
-In our case, the re-run yields bit-identical results, hence nothing new is saved.
+In our case, the rerun yields bit-identical results, hence nothing new is saved.
 
 .. runrecord:: _examples/repro-111
    :language: console
@@ -218,8 +218,8 @@ But as these inputs were registered in the dataset when we installed them, getti
 Only the remaining data (our code and the results) need to be kept and require a backup for long term archival.
 Everything else can be reobtained as needed, when needed.
 
-As DataLad knows everything needed about the inputs, including where to get the right version, we can re-run the analysis with a single command.
-Watch how DataLad reobtains all required data, re-runs the code, and checks that none of the results changed and need saving.
+As DataLad knows everything needed about the inputs, including where to get the right version, we can rerun the analysis with a single command.
+Watch how DataLad reobtains all required data, reruns the code, and checks that none of the results changed and need saving.
 
 .. runrecord:: _examples/repro-117
    :language: console

versioneer.py

@@ -262,7 +262,7 @@ To upgrade your project to a new release of Versioneer, do the following:
 * edit `setup.cfg` and `pyproject.toml`, if necessary,
   to include any new configuration settings indicated by the release notes.
   See [UPGRADING](./UPGRADING.md) for details.
-* re-run `versioneer install --[no-]vendor` in your source tree, to replace
+* rerun `versioneer install --[no-]vendor` in your source tree, to replace
   `SRC/_version.py`
 * commit any changed files
 
@@ -2140,12 +2140,12 @@ You will also need to edit your setup.py to use the results:
        cmdclass=versioneer.get_cmdclass(), ...)
 
 Please read the docstring in ./versioneer.py for configuration instructions,
-edit setup.cfg, and re-run the installer or 'python versioneer.py setup'.
+edit setup.cfg, and rerun the installer or 'python versioneer.py setup'.
 """
 
 SAMPLE_CONFIG = """
 # See the docstring in versioneer.py for instructions. Note that you must
-# re-run 'versioneer.py setup' after changing this section, and commit the
+# rerun 'versioneer.py setup' after changing this section, and commit the
 # resulting files.
 
 [versioneer]