--- a/HISTORY.txt	Sat Sep 24 09:48:40 2016 +0200
+++ b/HISTORY.txt	Sat Sep 24 09:49:20 2016 +0200
@@ -1,3 +1,13 @@
+Unreleased
+~~~~~~~~~~~~~
+
+Introduced configuration. More compact syntax for group definition
+(group.NAME), possibility to configure prioritized and ignored paths.
+
+Improved README.
+
+Fixed help texts (command names were swapped).
+
 
 0.6.0
 ~~~~~~~~~~~~~

--- a/README.txt	Sat Sep 24 09:48:40 2016 +0200
+++ b/README.txt	Sat Sep 24 09:49:20 2016 +0200
@@ -12,53 +12,119 @@
 
 .. sectnum::
 
-Usage
+Basic usage
 ================================================
 
-Simple::
+Execute::
 
     hg pushall
 
-pushes to all paths defined for the repository (all paths
-returned by ``hg paths`` - usually defined in ``.hg/hgrc``,
-but `Path Pattern`_ paths are also handled).
-
-There is also corresponding::
+to push to all remotes which are defined for the repository. Or::
 
     hg pullall
 
-Instead of using standard paths, you can define and use *groups*::
+to pull from all remotes in order.
+
+There are also::
+
+    hg incomingall
+
+    hg outgoingall
+
+Standard push/pull options can be given, for example::
+
+    hg pushall -f -B issue-13724
+
+    hg pullall -r stable --insecure
+
+Those commands iterate over all paths returned by ``hg paths``.  This
+usually means iterating over paths defined in ``[paths]`` section of
+``.hg/hgrc``, but `Path Pattern`_ paths are also handled. You can
+impact this behaviour by configuration, see below.
+
+
+Defining path groups
+================================================
+
+Instead of pushing/pulling everywhere, you can define and use *groups*::
 
     hg pushall -g publish
 
-pushes to all paths specified in the ``[publish]`` config
-section, which should look like this::
+pushes to all paths from the ``publish`` group (where ``publish`` is
+symbolic name of your choosing).
+
+There are two ways to define such a group:
+
+1. Define appropriate entry in ``[all_paths]`` section (either in ``.hg/hgrc``
+   or in your global ``~/.hgrc``). For example::
+
+     [all_paths]
+     group.publish = bitbucket github backup
+
+   (path aliases ``bitbucket``, ``github`` and ``backup`` must
+   be somehow defined).
+
+2. (Legacy method) Put the section of the same name in ``.hg/hgrc``,
+   and define all paths there. For example::
 
     [publish]
     bitbucket = ssh://hg@bitbucket.org/ludovicchabant/piecrust
     github = git+ssh://git@github.com:ludovicchabant/PieCrust.git
-    other = ssh://my@own/server
-    local = /some/other/place
+    backup = ssh://ludo@backup.local/piecrust
 
-All standard ``push`` and ``pull`` options can be used::
+   The syntax is the same as in standard ``[paths]`` section, just
+   name the section with the name of your group.
+
+   .. note::
 
-    hg pushall -b branch
+      Be careful to avoid conflicts with names which mean something
+      to Mercurial. For example ``web`` would be a bad name as ``[web]``
+      section configures ``hg serve`` behaviour, and ``ui`` would be
+      fatal as ``[ui]`` configures various basic Mercurial settings.
 
-or::
+I recommend the former method as it avoids the risk of conflicts,
+makes it easy to define groups globally instead of defining them for
+every repository (especially handy if you use `Path Pattern`_), and is
+more compact.
 
-    hg pullall --force
+Configuration
+=======================================================
+
+The extension can be configured using ``[all_paths]`` section of your
+global (``~/.hgrc``) or repository-level (``.hg/hgrc``) config file::
 
-etc.
+  [all_paths]
+  prioritize = platon department
+  ignore = bitbucket production
+  group.publish = github bitbucket
+  group.backup = homebackup awsbackup
 
-Finally, there are::
+``prioritize`` impacts the order, defines paths which are to be
+handled first (if present). This is mostly useful for ``pullall``
+where pulling from local fast computer before pulling from BitBucket
+server means saving some time and traffic. So::
 
-    hg incomingall
+  prioritize = platon department
+
+means: if path named ``platon`` is present, handle it first, then
+path named ``department``, only then follow to other paths.
 
-and
+``ignore`` lists paths which should be ignored, those remotes will
+be skipped. So::
+
+  ignore = bitbucket production
 
-    hg outgoingall
+means that ``hg pullall`` or ``hg pushall`` should not use
+``bitbucket`` path (in my case because this is HTTP remote, and I have
+also preferable ``bitssh``configured), and ``production`` path (as
+there I prefer to pull and push only on specific demand).
 
-which simply iterate over all paths.
+Both those settings impact only *default* commands (those run
+without ``-g GROUP`` option). In case of groups items are processed
+in the order they are specified in group definition.
+
+``group.«NAME»`` define group for ``-g «NAME»`` as described earlier. 
+
 
 Installation
 =======================================================