Show More
@@ -1,321 +1,314 b'' | |||||
1 | Extensions allow the creation of new features and using them directly from |
|
1 | Extensions allow the creation of new features and using them directly from | |
2 | the main hg command line as if they were built-in commands. The extensions |
|
2 | the main hg command line as if they were built-in commands. The extensions | |
3 | have full access to the *internal* API. |
|
3 | have full access to the *internal* API. | |
4 |
|
4 | |||
5 | Use of Mercurial's internal API very likely makes your code subject to |
|
5 | Use of Mercurial's internal API very likely makes your code subject to | |
6 | Mercurial's license. Before going any further, read the License page. |
|
6 | Mercurial's license. Before going any further, read the License page. | |
7 |
|
7 | |||
8 | There are NO guarantees that third-party code calling into Mercurial's |
|
8 | There are NO guarantees that third-party code calling into Mercurial's | |
9 | internals won't break from release to release. If you do use Mercurial's API |
|
9 | internals won't break from release to release. If you do use Mercurial's API | |
10 | for published third-party code, we expect you to test your code before each |
|
10 | for published third-party code, we expect you to test your code before each | |
11 | major Mercurial release. This will prevent various bug reports from your users |
|
11 | major Mercurial release. This will prevent various bug reports from your users | |
12 | when they upgrade their copy of Mercurial. |
|
12 | when they upgrade their copy of Mercurial. | |
13 |
|
13 | |||
14 | File Layout |
|
14 | File Layout | |
15 | =========== |
|
15 | =========== | |
16 |
|
16 | |||
17 | Extensions are usually written as simple python modules. Larger ones are |
|
17 | Extensions are usually written as simple python modules. Larger ones are | |
18 | better split into multiple modules of a single package (see the convert |
|
18 | better split into multiple modules of a single package (see the convert | |
19 | extension). The package root module gives its name to the extension and |
|
19 | extension). The package root module gives its name to the extension and | |
20 | implements the ``cmdtable`` and optional callbacks described below. |
|
20 | implements the ``cmdtable`` and optional callbacks described below. | |
21 |
|
21 | |||
22 | Command table |
|
22 | Command table | |
23 | ============= |
|
23 | ============= | |
24 |
|
24 | |||
25 | To write your own extension, your python module can provide an optional dict |
|
25 | To write your own extension, your python module can provide an optional dict | |
26 | named ``cmdtable`` with entries describing each command. A command should be |
|
26 | named ``cmdtable`` with entries describing each command. A command should be | |
27 | registered to the ``cmdtable`` by ``@command`` decorator. |
|
27 | registered to the ``cmdtable`` by ``@command`` decorator. | |
28 |
|
28 | |||
29 | Example using ``@command`` decorator (requires Mercurial 1.9):: |
|
29 | Example using ``@command`` decorator (requires Mercurial 1.9):: | |
30 |
|
30 | |||
31 | from mercurial import cmdutil |
|
31 | from mercurial import cmdutil | |
32 | from mercurial.i18n import _ |
|
32 | from mercurial.i18n import _ | |
33 |
|
33 | |||
34 | cmdtable = {} |
|
34 | cmdtable = {} | |
35 | command = cmdutil.command(cmdtable) |
|
35 | command = cmdutil.command(cmdtable) | |
36 |
|
36 | |||
37 | @command('print-parents', |
|
37 | @command('print-parents', | |
38 | [('s', 'short', None, _('print short form')), |
|
38 | [('s', 'short', None, _('print short form')), | |
39 | ('l', 'long', None, _('print long form'))], |
|
39 | ('l', 'long', None, _('print long form'))], | |
40 | _('[options] node')) |
|
40 | _('[options] node')) | |
41 | def printparents(ui, repo, node, **opts): |
|
41 | def printparents(ui, repo, node, **opts): | |
42 | ... |
|
42 | ... | |
43 |
|
43 | |||
44 | The cmdtable dictionary |
|
44 | The cmdtable dictionary | |
45 | ----------------------- |
|
45 | ----------------------- | |
46 |
|
46 | |||
47 | The ``cmdtable`` dictionary uses as key the new command names, and, as value, |
|
47 | The ``cmdtable`` dictionary uses as key the new command names, and, as value, | |
48 | a tuple containing: |
|
48 | a tuple containing: | |
49 |
|
49 | |||
50 | 1. the function to be called when the command is used. |
|
50 | 1. the function to be called when the command is used. | |
51 | 2. a list of options the command can take. |
|
51 | 2. a list of options the command can take. | |
52 | 3. a command line synopsis for the command (the function docstring is used for |
|
52 | 3. a command line synopsis for the command (the function docstring is used for | |
53 | the full help). |
|
53 | the full help). | |
54 |
|
54 | |||
55 | List of options |
|
55 | List of options | |
56 | --------------- |
|
56 | --------------- | |
57 |
|
57 | |||
58 | All the command flag options are documented in the mercurial/fancyopts.py |
|
58 | All the command flag options are documented in the mercurial/fancyopts.py | |
59 | sources. |
|
59 | sources. | |
60 |
|
60 | |||
61 | The options list is a list of tuples containing: |
|
61 | The options list is a list of tuples containing: | |
62 |
|
62 | |||
63 | 1. the short option letter, or ``''`` if no short option is available |
|
63 | 1. the short option letter, or ``''`` if no short option is available | |
64 | (for example, ``o`` for a ``-o`` option). |
|
64 | (for example, ``o`` for a ``-o`` option). | |
65 | 2. the long option name (for example, ``option`` for a ``--option`` option). |
|
65 | 2. the long option name (for example, ``option`` for a ``--option`` option). | |
66 | 3. a default value for the option. |
|
66 | 3. a default value for the option. | |
67 | 4. a help string for the option (it's possible to omit the "hg newcommand" |
|
67 | 4. a help string for the option (it's possible to omit the "hg newcommand" | |
68 | part and only the options and parameter substring is needed). |
|
68 | part and only the options and parameter substring is needed). | |
69 |
|
69 | |||
70 | Command function signatures |
|
70 | Command function signatures | |
71 | --------------------------- |
|
71 | --------------------------- | |
72 |
|
72 | |||
73 | Functions that implement new commands always receive a ``ui`` and usually |
|
73 | Functions that implement new commands always receive a ``ui`` and usually | |
74 | a ``repo`` parameter. The rest of parameters are taken from the command line |
|
74 | a ``repo`` parameter. The rest of parameters are taken from the command line | |
75 | items that don't start with a dash and are passed in the same order they were |
|
75 | items that don't start with a dash and are passed in the same order they were | |
76 | written. If no default value is given in the parameter list they are required. |
|
76 | written. If no default value is given in the parameter list they are required. | |
77 |
|
77 | |||
78 | If there is no repo to be associated with the command and consequently no |
|
78 | If there is no repo to be associated with the command and consequently no | |
79 | ``repo`` passed, then ``norepo=True`` should be passed to the ``@command`` |
|
79 | ``repo`` passed, then ``norepo=True`` should be passed to the ``@command`` | |
80 | decorator:: |
|
80 | decorator:: | |
81 |
|
81 | |||
82 | @command('mycommand', [], norepo=True) |
|
82 | @command('mycommand', [], norepo=True) | |
83 | def mycommand(ui, **opts): |
|
83 | def mycommand(ui, **opts): | |
84 | ... |
|
84 | ... | |
85 |
|
85 | |||
86 | For examples of ``norepo``, see the convert extension. |
|
86 | For examples of ``norepo``, see the convert extension. | |
87 |
|
87 | |||
88 | Command function docstrings |
|
88 | Command function docstrings | |
89 | =========================== |
|
89 | =========================== | |
90 |
|
90 | |||
91 | The docstring of your function is used as the main help text, shown by |
|
91 | The docstring of your function is used as the main help text, shown by | |
92 | ``hg help mycommand``. The docstring should be formatted using a simple |
|
92 | ``hg help mycommand``. The docstring should be formatted using a simple | |
93 | subset of reStructuredText markup. The supported constructs include: |
|
93 | subset of reStructuredText markup. The supported constructs include: | |
94 |
|
94 | |||
95 | Paragraphs:: |
|
95 | Paragraphs:: | |
96 |
|
96 | |||
97 | This is a paragraph. |
|
97 | This is a paragraph. | |
98 |
|
98 | |||
99 | Paragraphs are separated |
|
99 | Paragraphs are separated | |
100 | by blank lines. |
|
100 | by blank lines. | |
101 |
|
101 | |||
102 | A verbatim block is introduced with a double colon followed by an indented |
|
102 | A verbatim block is introduced with a double colon followed by an indented | |
103 | block. The double colon is turned into a single colon on display:: |
|
103 | block. The double colon is turned into a single colon on display:: | |
104 |
|
104 | |||
105 | Some text:: |
|
105 | Some text:: | |
106 |
|
106 | |||
107 | verbatim |
|
107 | verbatim | |
108 | text |
|
108 | text | |
109 | !! |
|
109 | !! | |
110 |
|
110 | |||
111 | We have field lists:: |
|
111 | We have field lists:: | |
112 |
|
112 | |||
113 | :key1: value1 |
|
113 | :key1: value1 | |
114 | :key2: value2 |
|
114 | :key2: value2 | |
115 |
|
115 | |||
116 | Bullet lists:: |
|
116 | Bullet lists:: | |
117 |
|
117 | |||
118 | - foo |
|
118 | - foo | |
119 | - bar |
|
119 | - bar | |
120 |
|
120 | |||
121 | Enumerated lists:: |
|
121 | Enumerated lists:: | |
122 |
|
122 | |||
123 | 1. foo |
|
123 | 1. foo | |
124 | 2. bar |
|
124 | 2. bar | |
125 |
|
125 | |||
126 | Inline markup:: |
|
126 | Inline markup:: | |
127 |
|
127 | |||
128 | ``*bold*``, ``monospace``, :hg:`command` |
|
128 | ``*bold*``, ``monospace``, :hg:`command` | |
129 |
|
129 | |||
130 | Mark Mercurial commands with ``:hg:`` to make a nice link to the corresponding |
|
130 | Mark Mercurial commands with ``:hg:`` to make a nice link to the corresponding | |
131 | documentation. We'll expand the support if new constructs can be parsed |
|
131 | documentation. We'll expand the support if new constructs can be parsed | |
132 | without too much trouble. |
|
132 | without too much trouble. | |
133 |
|
133 | |||
134 | Communicating with the user |
|
134 | Communicating with the user | |
135 | =========================== |
|
135 | =========================== | |
136 |
|
136 | |||
137 | Besides the ``ui`` methods, like ``ui.write(*msg)`` or |
|
137 | Besides the ``ui`` methods, like ``ui.write(*msg)`` or | |
138 | ``ui.prompt(msg, default="y")``, an extension can add help text for each |
|
138 | ``ui.prompt(msg, default="y")``, an extension can add help text for each | |
139 | of its commands and the extension itself. |
|
139 | of its commands and the extension itself. | |
140 |
|
140 | |||
141 | The module docstring will be used as help string when ``hg help extensionname`` |
|
141 | The module docstring will be used as help string when ``hg help extensionname`` | |
142 | is used and, similarly, the help string for a command and the docstring |
|
142 | is used and, similarly, the help string for a command and the docstring | |
143 | belonging to the function that's wrapped by the command will be shown when |
|
143 | belonging to the function that's wrapped by the command will be shown when | |
144 | ``hg help command`` is invoked. |
|
144 | ``hg help command`` is invoked. | |
145 |
|
145 | |||
146 | Setup Callbacks |
|
146 | Setup Callbacks | |
147 | =============== |
|
147 | =============== | |
148 |
|
148 | |||
149 | Extensions are loaded in phases. All extensions are processed in a given phase |
|
149 | Extensions are loaded in phases. All extensions are processed in a given phase | |
150 | before the next phase begins. In the first phase, all extension modules are |
|
150 | before the next phase begins. In the first phase, all extension modules are | |
151 | loaded and registered with Mercurial. This means that you can find all enabled |
|
151 | loaded and registered with Mercurial. This means that you can find all enabled | |
152 | extensions with ``extensions.find`` in the following phases. |
|
152 | extensions with ``extensions.find`` in the following phases. | |
153 |
|
153 | |||
154 |
|
|
154 | Extension setup | |
155 | -------- |
|
155 | --------------- | |
156 |
|
156 | |||
157 | Extensions can implement an optional callback named ``uisetup``. ``uisetup`` |
|
157 | There are two callbacks to be called when extensions are loaded, named | |
158 | is called when the extension is first loaded and receives a ui object:: |
|
158 | ``uisetup`` and ``extsetup``. ``uisetup`` is called first for each extension, | |
|
159 | then ``extsetup`` is called. This means ``extsetup`` can be useful in case | |||
|
160 | one extension optionally depends on another extension. | |||
|
161 | ||||
|
162 | Both ``uisetup`` and ``extsetup`` receive a ui object:: | |||
159 |
|
163 | |||
160 | def uisetup(ui): |
|
164 | def uisetup(ui): | |
161 | # ... |
|
165 | # ... | |
162 |
|
166 | |||
163 | Extension setup |
|
167 | def extsetup(ui): | |
164 | --------------- |
|
|||
165 |
|
||||
166 | Extensions can implement an optional callback named ``extsetup``. It is |
|
|||
167 | called after all the extension are loaded, and can be useful in case one |
|
|||
168 | extension optionally depends on another extension. Signature:: |
|
|||
169 |
|
||||
170 | def extsetup(): |
|
|||
171 | # ... |
|
168 | # ... | |
172 |
|
169 | |||
173 | Mercurial version 8e6019b16a7d and later (that is post-1.3.1) will pass |
|
170 | In Mercurial 1.3.1 or earlier, ``extsetup`` takes no argument. | |
174 | a ``ui``` argument to ``extsetup``:: |
|
|||
175 |
|
||||
176 | def extsetup(ui): |
|
|||
177 | # ... |
|
|||
178 |
|
171 | |||
179 | Command table setup |
|
172 | Command table setup | |
180 | ------------------- |
|
173 | ------------------- | |
181 |
|
174 | |||
182 | After ``extsetup``, the ``cmdtable`` is copied into the global command table |
|
175 | After ``extsetup``, the ``cmdtable`` is copied into the global command table | |
183 | in Mercurial. |
|
176 | in Mercurial. | |
184 |
|
177 | |||
185 | Repository setup |
|
178 | Repository setup | |
186 | ---------------- |
|
179 | ---------------- | |
187 |
|
180 | |||
188 | Extensions can implement an optional callback named ``reposetup``. It is |
|
181 | Extensions can implement an optional callback named ``reposetup``. It is | |
189 | called after the main Mercurial repository initialization, and can be used |
|
182 | called after the main Mercurial repository initialization, and can be used | |
190 | to setup any local state the extension might need. |
|
183 | to setup any local state the extension might need. | |
191 |
|
184 | |||
192 | As other command functions it receives an ``ui`` object and a ``repo`` object |
|
185 | As other command functions it receives an ``ui`` object and a ``repo`` object | |
193 | (no additional parameters for this, though):: |
|
186 | (no additional parameters for this, though):: | |
194 |
|
187 | |||
195 | def reposetup(ui, repo): |
|
188 | def reposetup(ui, repo): | |
196 | #do initialization here. |
|
189 | #do initialization here. | |
197 |
|
190 | |||
198 | It is important to take into account that the ``ui`` object that is received |
|
191 | It is important to take into account that the ``ui`` object that is received | |
199 | by the ``reposetup`` function is not the same as the one received by the |
|
192 | by the ``reposetup`` function is not the same as the one received by the | |
200 | ``uisetup`` and ``extsetup`` functions. This is particularly important when |
|
193 | ``uisetup`` and ``extsetup`` functions. This is particularly important when | |
201 | setting up hooks as described in the following section, since not all hooks |
|
194 | setting up hooks as described in the following section, since not all hooks | |
202 | use the same ``ui`` object and hence different hooks must be configured in |
|
195 | use the same ``ui`` object and hence different hooks must be configured in | |
203 | different setup functions. |
|
196 | different setup functions. | |
204 |
|
197 | |||
205 | Wrapping methods on the ui and repo classes |
|
198 | Wrapping methods on the ui and repo classes | |
206 | ------------------------------------------- |
|
199 | ------------------------------------------- | |
207 |
|
200 | |||
208 | Because extensions can be loaded *per repository*, you should avoid using |
|
201 | Because extensions can be loaded *per repository*, you should avoid using | |
209 | ``extensions.wrapfunction()`` on methods of the ``ui`` and ``repo`` objects. |
|
202 | ``extensions.wrapfunction()`` on methods of the ``ui`` and ``repo`` objects. | |
210 | Instead, create a subclass of the specific class of the instance passed into |
|
203 | Instead, create a subclass of the specific class of the instance passed into | |
211 | the ``*setup()`` hook; e.g. use ``ui.__class__`` as the base class, then |
|
204 | the ``*setup()`` hook; e.g. use ``ui.__class__`` as the base class, then | |
212 | reassign your new class to ``ui.__class__`` again. Mercurial will then use |
|
205 | reassign your new class to ``ui.__class__`` again. Mercurial will then use | |
213 | your updated ``ui`` or ``repo`` instance only for repositories where your |
|
206 | your updated ``ui`` or ``repo`` instance only for repositories where your | |
214 | extension is enabled (or copies thereof, reusing your new class). |
|
207 | extension is enabled (or copies thereof, reusing your new class). | |
215 |
|
208 | |||
216 | For example:: |
|
209 | For example:: | |
217 |
|
210 | |||
218 | def uisetup(ui): |
|
211 | def uisetup(ui): | |
219 | class echologui(ui.__class__): |
|
212 | class echologui(ui.__class__): | |
220 | def log(self, service, *msg, **opts): |
|
213 | def log(self, service, *msg, **opts): | |
221 | if msg: |
|
214 | if msg: | |
222 | self.write('%s: %s\n' % (service, msg[0] % msg[1:])) |
|
215 | self.write('%s: %s\n' % (service, msg[0] % msg[1:])) | |
223 | super(echologui, self).log(service, *msg, **opts) |
|
216 | super(echologui, self).log(service, *msg, **opts) | |
224 |
|
217 | |||
225 | ui.__class__ = echologui |
|
218 | ui.__class__ = echologui | |
226 |
|
219 | |||
227 | Configuring Hooks |
|
220 | Configuring Hooks | |
228 | ================= |
|
221 | ================= | |
229 |
|
222 | |||
230 | Some extensions must use hooks to do their work. These required hooks can |
|
223 | Some extensions must use hooks to do their work. These required hooks can | |
231 | be configured manually by the user by modifying the ``[hook]`` section of |
|
224 | be configured manually by the user by modifying the ``[hook]`` section of | |
232 | their hgrc, but they can also be configured automatically by calling the |
|
225 | their hgrc, but they can also be configured automatically by calling the | |
233 | ``ui.setconfig('hooks', ...)`` function in one of the setup functions |
|
226 | ``ui.setconfig('hooks', ...)`` function in one of the setup functions | |
234 | described above. |
|
227 | described above. | |
235 |
|
228 | |||
236 | The main difference between manually modifying the hooks section in the hgrc |
|
229 | The main difference between manually modifying the hooks section in the hgrc | |
237 | and using ``ui.setconfig()`` is that when using ``ui.setconfig()`` you have |
|
230 | and using ``ui.setconfig()`` is that when using ``ui.setconfig()`` you have | |
238 | access to the actual hook function object, which you can pass directly to |
|
231 | access to the actual hook function object, which you can pass directly to | |
239 | ``ui.setconfig()``, while when you use the hooks section of the hgrc file |
|
232 | ``ui.setconfig()``, while when you use the hooks section of the hgrc file | |
240 | you must refer to the hook function by using the |
|
233 | you must refer to the hook function by using the | |
241 | ``python:modulename.functioname`` idiom (e.g. ``python:hgext.notify.hook``). |
|
234 | ``python:modulename.functioname`` idiom (e.g. ``python:hgext.notify.hook``). | |
242 |
|
235 | |||
243 | For example:: |
|
236 | For example:: | |
244 |
|
237 | |||
245 | # Define hooks -- note that the actual function name it irrelevant. |
|
238 | # Define hooks -- note that the actual function name it irrelevant. | |
246 | def preupdatehook(ui, repo, **kwargs): |
|
239 | def preupdatehook(ui, repo, **kwargs): | |
247 | ui.write("Pre-update hook triggered\n") |
|
240 | ui.write("Pre-update hook triggered\n") | |
248 |
|
241 | |||
249 | def updatehook(ui, repo, **kwargs): |
|
242 | def updatehook(ui, repo, **kwargs): | |
250 | ui.write("Update hook triggered\n") |
|
243 | ui.write("Update hook triggered\n") | |
251 |
|
244 | |||
252 | def uisetup(ui): |
|
245 | def uisetup(ui): | |
253 | # When pre-<cmd> and post-<cmd> hooks are configured by means of |
|
246 | # When pre-<cmd> and post-<cmd> hooks are configured by means of | |
254 | # the ui.setconfig() function, you must use the ui object passed |
|
247 | # the ui.setconfig() function, you must use the ui object passed | |
255 | # to uisetup or extsetup. |
|
248 | # to uisetup or extsetup. | |
256 | ui.setconfig("hooks", "pre-update.myextension", preupdatehook) |
|
249 | ui.setconfig("hooks", "pre-update.myextension", preupdatehook) | |
257 |
|
250 | |||
258 | def reposetup(ui, repo): |
|
251 | def reposetup(ui, repo): | |
259 | # Repository-specific hooks can be configured here. These include |
|
252 | # Repository-specific hooks can be configured here. These include | |
260 | # the update hook. |
|
253 | # the update hook. | |
261 | ui.setconfig("hooks", "update.myextension", updatehook) |
|
254 | ui.setconfig("hooks", "update.myextension", updatehook) | |
262 |
|
255 | |||
263 | Note how different hooks may need to be configured in different setup |
|
256 | Note how different hooks may need to be configured in different setup | |
264 | functions. In the example you can see that the ``update`` hook must be |
|
257 | functions. In the example you can see that the ``update`` hook must be | |
265 | configured in the ``reposetup`` function, while the ``pre-update`` hook |
|
258 | configured in the ``reposetup`` function, while the ``pre-update`` hook | |
266 | must be configured on the ``uisetup`` or the ``extsetup`` functions. |
|
259 | must be configured on the ``uisetup`` or the ``extsetup`` functions. | |
267 |
|
260 | |||
268 | Marking compatible versions |
|
261 | Marking compatible versions | |
269 | =========================== |
|
262 | =========================== | |
270 |
|
263 | |||
271 | Every extension should use the ``testedwith`` variable to specify Mercurial |
|
264 | Every extension should use the ``testedwith`` variable to specify Mercurial | |
272 | releases it's known to be compatible with. This helps us and users diagnose |
|
265 | releases it's known to be compatible with. This helps us and users diagnose | |
273 | where problems are coming from:: |
|
266 | where problems are coming from:: | |
274 |
|
267 | |||
275 | testedwith = '2.0 2.0.1 2.1 2.1.1 2.1.2' |
|
268 | testedwith = '2.0 2.0.1 2.1 2.1.1 2.1.2' | |
276 |
|
269 | |||
277 | Do not use the ``internal`` marker in third-party extensions; we will |
|
270 | Do not use the ``internal`` marker in third-party extensions; we will | |
278 | immediately drop all bug reports mentioning your extension if we catch you |
|
271 | immediately drop all bug reports mentioning your extension if we catch you | |
279 | doing this. |
|
272 | doing this. | |
280 |
|
273 | |||
281 | Similarly, an extension can use the ``buglink`` variable to specify how users |
|
274 | Similarly, an extension can use the ``buglink`` variable to specify how users | |
282 | should report issues with the extension. This link will be included in the |
|
275 | should report issues with the extension. This link will be included in the | |
283 | error message if the extension produces errors:: |
|
276 | error message if the extension produces errors:: | |
284 |
|
277 | |||
285 | buglink = 'https://bitbucket.org/USER/REPO/issues' |
|
278 | buglink = 'https://bitbucket.org/USER/REPO/issues' | |
286 |
|
279 | |||
287 | Wrap up: what belongs where? |
|
280 | Wrap up: what belongs where? | |
288 | ============================ |
|
281 | ============================ | |
289 |
|
282 | |||
290 | You will find here a list of most common tasks, based on setups from the |
|
283 | You will find here a list of most common tasks, based on setups from the | |
291 | extensions included in Mercurial core. |
|
284 | extensions included in Mercurial core. | |
292 |
|
285 | |||
293 | uisetup |
|
286 | uisetup | |
294 | ------- |
|
287 | ------- | |
295 |
|
288 | |||
296 | * Changes to ``ui.__class__`` . The ``ui`` object that will be used to run |
|
289 | * Changes to ``ui.__class__`` . The ``ui`` object that will be used to run | |
297 | the command has not yet been created. Changes made here will affect ``ui`` |
|
290 | the command has not yet been created. Changes made here will affect ``ui`` | |
298 | objects created after this, and in particular the ``ui`` that will be passed |
|
291 | objects created after this, and in particular the ``ui`` that will be passed | |
299 | to ``runcommand`` |
|
292 | to ``runcommand`` | |
300 | * Command wraps (``extensions.wrapcommand``) |
|
293 | * Command wraps (``extensions.wrapcommand``) | |
301 | * Changes that need to be visible by other extensions: because initialization |
|
294 | * Changes that need to be visible by other extensions: because initialization | |
302 | occurs in phases (all extensions run ``uisetup``, then all run ``extsetup``), |
|
295 | occurs in phases (all extensions run ``uisetup``, then all run ``extsetup``), | |
303 | a change made here will be visible by other extensions during ``extsetup``. |
|
296 | a change made here will be visible by other extensions during ``extsetup``. | |
304 | * Monkeypatches or function wraps (``extensions.wrapfunction``) of ``dispatch`` |
|
297 | * Monkeypatches or function wraps (``extensions.wrapfunction``) of ``dispatch`` | |
305 | module members |
|
298 | module members | |
306 | * Setup of ``pre-*`` and ``post-*`` hooks |
|
299 | * Setup of ``pre-*`` and ``post-*`` hooks | |
307 | * ``pushkey`` setup |
|
300 | * ``pushkey`` setup | |
308 |
|
301 | |||
309 | extsetup |
|
302 | extsetup | |
310 | -------- |
|
303 | -------- | |
311 |
|
304 | |||
312 | * Changes depending on the status of other extensions. (``if extensions.find('mq')``) |
|
305 | * Changes depending on the status of other extensions. (``if extensions.find('mq')``) | |
313 | * Add a global option to all commands |
|
306 | * Add a global option to all commands | |
314 | * Extend revsets |
|
307 | * Extend revsets | |
315 |
|
308 | |||
316 | reposetup |
|
309 | reposetup | |
317 | --------- |
|
310 | --------- | |
318 |
|
311 | |||
319 | * All hooks but ``pre-*`` and ``post-*`` |
|
312 | * All hooks but ``pre-*`` and ``post-*`` | |
320 | * Modify configuration variables |
|
313 | * Modify configuration variables | |
321 | * Changes to ``repo.__class__``, ``repo.dirstate.__class__`` |
|
314 | * Changes to ``repo.__class__``, ``repo.dirstate.__class__`` |
General Comments 0
You need to be logged in to leave comments.
Login now