Mercurial > hg-allpaths

comparison README.txt @ 36:c27e23a3509c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Initial work on configuration - prioritized paths - ignored paths - compact group definition syntax So far just README description for how they are to work.
author Marcin Kasperski <Marcin.Kasperski@mekk.waw.pl>
date Sat, 24 Sep 2016 09:49:20 +0200
parents 3f8c4b4a5cc6
children b8a7342fbf23
comparison
equal deleted inserted replaced
35:6dae5ed53f22 36:c27e23a3509c
10 :local: 10 :local:
11 :depth: 2 11 :depth: 2
12 12
13 .. sectnum:: 13 .. sectnum::
14 14
15 Usage 15 Basic usage
16 ================================================ 16 ================================================
17 17
18 Simple:: 18 Execute::
19 19
20 hg pushall 20 hg pushall
21 21
22 pushes to all paths defined for the repository (all paths 22 to push to all remotes which are defined for the repository. Or::
23 returned by ``hg paths`` - usually defined in ``.hg/hgrc``,
24 but `Path Pattern`_ paths are also handled).
25
26 There is also corresponding::
27 23
28 hg pullall 24 hg pullall
29 25
30 Instead of using standard paths, you can define and use *groups*:: 26 to pull from all remotes in order.
27
28 There are also::
29
30 hg incomingall
31
32 hg outgoingall
33
34 Standard push/pull options can be given, for example::
35
36 hg pushall -f -B issue-13724
37
38 hg pullall -r stable --insecure
39
40 Those commands iterate over all paths returned by ``hg paths``. This
41 usually means iterating over paths defined in ``[paths]`` section of
42 ``.hg/hgrc``, but `Path Pattern`_ paths are also handled. You can
43 impact this behaviour by configuration, see below.
44
45
46 Defining path groups
47 ================================================
48
49 Instead of pushing/pulling everywhere, you can define and use *groups*::
31 50
32 hg pushall -g publish 51 hg pushall -g publish
33 52
34 pushes to all paths specified in the ``[publish]`` config 53 pushes to all paths from the ``publish`` group (where ``publish`` is
35 section, which should look like this:: 54 symbolic name of your choosing).
55
56 There are two ways to define such a group:
57
58 1. Define appropriate entry in ``[all_paths]`` section (either in ``.hg/hgrc``
59 or in your global ``~/.hgrc``). For example::
60
61 [all_paths]
62 group.publish = bitbucket github backup
63
64 (path aliases ``bitbucket``, ``github`` and ``backup`` must
65 be somehow defined).
66
67 2. (Legacy method) Put the section of the same name in ``.hg/hgrc``,
68 and define all paths there. For example::
36 69
37 [publish] 70 [publish]
38 bitbucket = ssh://hg@bitbucket.org/ludovicchabant/piecrust 71 bitbucket = ssh://hg@bitbucket.org/ludovicchabant/piecrust
39 github = git+ssh://git@github.com:ludovicchabant/PieCrust.git 72 github = git+ssh://git@github.com:ludovicchabant/PieCrust.git
40 other = ssh://my@own/server 73 backup = ssh://ludo@backup.local/piecrust
41 local = /some/other/place
42 74
43 All standard ``push`` and ``pull`` options can be used:: 75 The syntax is the same as in standard ``[paths]`` section, just
76 name the section with the name of your group.
44 77
45 hg pushall -b branch 78 .. note::
46 79
47 or:: 80 Be careful to avoid conflicts with names which mean something
81 to Mercurial. For example ``web`` would be a bad name as ``[web]``
82 section configures ``hg serve`` behaviour, and ``ui`` would be
83 fatal as ``[ui]`` configures various basic Mercurial settings.
48 84
49 hg pullall --force 85 I recommend the former method as it avoids the risk of conflicts,
86 makes it easy to define groups globally instead of defining them for
87 every repository (especially handy if you use `Path Pattern`_), and is
88 more compact.
50 89
51 etc. 90 Configuration
91 =======================================================
52 92
53 Finally, there are:: 93 The extension can be configured using ``[all_paths]`` section of your
94 global (``~/.hgrc``) or repository-level (``.hg/hgrc``) config file::
54 95
55 hg incomingall 96 [all_paths]
97 prioritize = platon department
98 ignore = bitbucket production
99 group.publish = github bitbucket
100 group.backup = homebackup awsbackup
56 101
57 and 102 ``prioritize`` impacts the order, defines paths which are to be
103 handled first (if present). This is mostly useful for ``pullall``
104 where pulling from local fast computer before pulling from BitBucket
105 server means saving some time and traffic. So::
58 106
59 hg outgoingall 107 prioritize = platon department
60 108
61 which simply iterate over all paths. 109 means: if path named ``platon`` is present, handle it first, then
110 path named ``department``, only then follow to other paths.
111
112 ``ignore`` lists paths which should be ignored, those remotes will
113 be skipped. So::
114
115 ignore = bitbucket production
116
117 means that ``hg pullall`` or ``hg pushall`` should not use
118 ``bitbucket`` path (in my case because this is HTTP remote, and I have
119 also preferable ``bitssh``configured), and ``production`` path (as
120 there I prefer to pull and push only on specific demand).
121
122 Both those settings impact only *default* commands (those run
123 without ``-g GROUP`` option). In case of groups items are processed
124 in the order they are specified in group definition.
125
126 ``group.«NAME»`` define group for ``-g «NAME»`` as described earlier.
127
62 128
63 Installation 129 Installation
64 ======================================================= 130 =======================================================
65 131
66 From PyPi 132 From PyPi