← Back to branch summary

~bzr/ubuntu/lucid/bzr/beta-ppa

« back to all changes in this revision

Viewing changes to bzrlib/help_topics/en/configuration.txt

  • Committer: Martin Pool
  • Date: 2010-07-02 07:29:40 UTC
  • mfrom: (129.1.7 packaging-karmic)
  • Revision ID: mbp@sourcefrog.net-20100702072940-hpzq5elg8wjve8rh
http://bugs.debian.org/452024
http://bugs.debian.org/464688
http://bugs.debian.org/523595
http://bugs.debian.org/526233
http://bugs.debian.org/537708
http://bugs.debian.org/555336
http://bugs.debian.org/555343
https://launchpad.net/bugs/249452
https://launchpad.net/bugs/385074
* PPA rebuild.
* PPA rebuild for Karmic.
* PPA rebuild for Jaunty.
* PPA rebuild for Hardy.
* From postinst, actually remove the example bash completion scripts.
  (LP: #249452)
* New upstream release.
* New upstream release.
* New upstream release.
* Revert change to Build-depends: Dapper does not have python-central.
  Should be python-support..
* Target ppa..
* Target ppa..
* Target ppa..
* Target ppa..
* New upstream release.
* Switch to dpkg-source 3.0 (quilt) format.
* Bump standards version to 3.8.4.
* Remove embedded copy of python-configobj. Closes: #555336
* Remove embedded copy of python-elementtree. Closes: #555343
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* debian/control: Fix obsolete-relation-form-in-source
  lintian warning. 
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Split out docs into bzr-doc package.
* New upstream release.
* Added John Francesco Ferlito to Uploaders.
* Fix install path to quick-reference guide
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to doc paths changing
* New upstream release.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to doc paths changing
* New upstream release.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to doc paths changing
* New upstream release.
* Fix FTBFS due to path changes, again, again.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to path changes.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Bump standards version to 3.8.3.
* Remove unused patch system.
* New upstream release.
* New upstream release.
* New upstream release.
* Fix copy and paste tab error in .install file
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
 + Fixes compatibility with Python 2.4. Closes: #537708
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream version.
* Bump standards version to 3.8.2.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Add python-pyrex to build-deps to ensure C extensions are always build.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Split documentation into bzr-doc package. ((LP: #385074)
* Multiple packaging changes to make us more linitan clean.
* New upstream release.
* Split documentation into bzr-doc package. ((LP: #385074)
* Multiple packaging changes to make us more linitan clean.
* New upstream release.
* Split documentation into bzr-doc package. ((LP: #385074)
* Multiple packaging changes to make us more linitan clean.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Fix API compatibility version. (Closes: #526233)
* New upstream release.
  + Fixes default format for upgrade command. (Closes: #464688)
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Add missing dependency on zlib development library. (Closes:
  #523595)
* Add zlib build-depends.
* Add zlib build-depends.
* Add zlib build-depends.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Move to section vcs.
* Bump standards version to 3.8.1.
* New upstream release.
* Remove temporary patch for missing .c files from distribution
* New upstream release.
* Remove temporary patch for missing .c files from distribution
* New upstream release.
* Remove temporary patch for missing .c files from distribution
* Add temporary patch for missing .c files from distribution
* Add temporary patch for missing .c files from distribution
* Add temporary patch for missing .c files from distribution
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Recommend ca-certificates. (Closes: #452024)
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Update watch file. bazaar now uses launchpad to host its sources.
* Remove patch for inventory root revision copy, applied upstream.
* New upstream release.
* New upstream release.
* New upstream release
* Force removal of files installed in error to /etc/bash_completion.d/
  (LP: #249452)
* New upstream release.
* New upstream release
* New upstream release.
* Bump standards version.
* Include patch for inventory root revision copy, required for bzr-svn.
* New upstream release.
* Remove unused lintian overrides.
* Correct the package version not to be native.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Final 1.5 release.
* New upstream release.
* New upstream release.
* New upstream release.
* Add myself as a co-maintainer.
* Add a Dm-Upload-Allowed: yes header.
* New upstream bugfix release.
* New upstream release.
* Final 1.3 release.
* New upstream release.
* First release candidate of the upcoming 1.3 release.
* Rebuild to fix the problem caused by a build with a broken python-central.
* New upstream release.
* Rebuild for dapper PPA.
* Apply Lamont's patches to fix build-dependencies on dapper.
  (See: https://bugs.launchpad.net/bzr/+bug/189915)

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/help_topics/en/configuration.txt
 
1
Configuration Settings
 
2
=======================
 
3
 
 
4
Environment settings
 
5
---------------------
 
6
 
 
7
While most configuration is handled by configuration files, some options
 
8
which may be semi-permanent can also be controlled through the environment.
 
9
 
 
10
BZR_EMAIL
 
11
~~~~~~~~~
 
12
 
 
13
Override the email id used by Bazaar.  Typical format::
 
14
 
 
15
  "John Doe <jdoe@example.com>"
 
16
 
 
17
See also the ``email`` configuration value.
 
18
 
 
19
BZR_PROGRESS_BAR
 
20
~~~~~~~~~~~~~~~~
 
21
 
 
22
Override the progress display.  Possible values are "none", "dots", "tty"
 
23
 
 
24
BZR_SIGQUIT_PDB
 
25
~~~~~~~~~~~~~~~
 
26
 
 
27
Control whether SIGQUIT behaves normally or invokes a breakin debugger.
 
28
 
 
29
* 0 = Standard SIGQUIT behavior (normally, exit with a core dump)
 
30
* 1 = Invoke breakin debugger (default)
 
31
 
 
32
BZR_HOME
 
33
~~~~~~~~
 
34
 
 
35
Override the home directory used by Bazaar.
 
36
 
 
37
BZR_SSH
 
38
~~~~~~~
 
39
 
 
40
Select a different SSH implementation.
 
41
 
 
42
BZR_PDB
 
43
~~~~~~~
 
44
 
 
45
Control whether to launch a debugger on error.
 
46
 
 
47
* 0 = Standard behavior
 
48
* 1 = Launch debugger
 
49
 
 
50
BZR_REMOTE_PATH
 
51
~~~~~~~~~~~~~~~
 
52
 
 
53
Path to the Bazaar executable to use when using the bzr+ssh protocol.
 
54
 
 
55
See also the ``bzr_remote_path`` configuration value.
 
56
 
 
57
BZR_EDITOR
 
58
~~~~~~~~~~
 
59
 
 
60
Path to the editor Bazaar should use for commit messages, etc.
 
61
 
 
62
BZR_PLUGIN_PATH
 
63
~~~~~~~~~~~~~~~
 
64
 
 
65
The path to the plugins directory that Bazaar should use.
 
66
If not set, Bazaar will search for plugins in:
 
67
 
 
68
* the user specific plugin directory (containing the ``user`` plugins),
 
69
 
 
70
* the bzrlib directory (containing the ``core`` plugins),
 
71
 
 
72
* the site specific plugin directory if applicable (containing
 
73
  the ``site`` plugins).
 
74
 
 
75
If ``BZR_PLUGIN_PATH`` is set in any fashion, it will change the
 
76
the way the plugin are searched. 
 
77
 
 
78
As for the ``PATH`` variables, if multiple directories are
 
79
specified in ``BZR_PLUGIN_PATH`` they should be separated by the
 
80
platform specific appropriate character (':' on Unix/Linux/etc,
 
81
';' on windows)
 
82
 
 
83
By default if ``BZR_PLUGIN_PATH`` is set, it replaces searching
 
84
in ``user``.  However it will continue to search in ``core`` and
 
85
``site`` unless they are explicitly removed.
 
86
 
 
87
If you need to change the order or remove one of these
 
88
directories, you should use special values:
 
89
 
 
90
* ``-user``, ``-core``, ``-site`` will remove the corresponding
 
91
  path from the default values,
 
92
 
 
93
* ``+user``, ``+core``, ``+site`` will add the corresponding path
 
94
  before the remaining default values (and also remove it from
 
95
  the default values).
 
96
 
 
97
Note that the special values 'user', 'core' and 'site' should be
 
98
used literally, they will be substituted by the corresponding,
 
99
platform specific, values.
 
100
 
 
101
Examples:
 
102
^^^^^^^^^
 
103
 
 
104
The examples below uses ':' as the separator, windows users
 
105
should use ';'.
 
106
 
 
107
Overriding the default user plugin directory:
 
108
``BZR_PLUGIN_PATH='/path/to/my/other/plugins'``
 
109
 
 
110
Disabling the site directory while retaining the user directory:
 
111
``BZR_PLUGIN_PATH='-site:+user'``
 
112
 
 
113
Disabling all plugins (better achieved with --no-plugins):
 
114
``BZR_PLUGIN_PATH='-user:-core:-site'``
 
115
 
 
116
Overriding the default site plugin directory:
 
117
``BZR_PLUGIN_PATH='/path/to/my/site/plugins:-site':+user``
 
118
 
 
119
 
 
120
 
 
121
BZRPATH
 
122
~~~~~~~
 
123
 
 
124
The path where Bazaar should look for shell plugin external commands.
 
125
 
 
126
 
 
127
Configuration files
 
128
-------------------
 
129
 
 
130
Location
 
131
~~~~~~~~
 
132
 
 
133
Configuration files are located in ``$HOME/.bazaar`` on Linux/Unix and
 
134
``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` on
 
135
Windows. (You can check the location for your system by using
 
136
``bzr version``.)
 
137
 
 
138
There are three primary configuration files in this location:
 
139
 
 
140
* ``bazaar.conf`` describes default configuration options,
 
141
 
 
142
* ``locations.conf`` describes configuration information for
 
143
  specific branch locations,
 
144
 
 
145
* ``authentication.conf`` describes credential information for
 
146
  remote servers.
 
147
 
 
148
Each branch can also contain a configuration file that sets values specific
 
149
to that branch. This file is found at ``.bzr/branch/branch.conf`` within the
 
150
branch. This file is visible to all users of a branch, if you wish to override
 
151
one of the values for a branch with a setting that is specific to you then you
 
152
can do so in ``locations.conf``.
 
153
 
 
154
General format
 
155
~~~~~~~~~~~~~~
 
156
 
 
157
An ini file has three types of contructs: section headers, section
 
158
variables and comments.
 
159
 
 
160
Comments
 
161
^^^^^^^^
 
162
 
 
163
A comment is any line that starts with a "#" (sometimes called a "hash
 
164
mark", "pound sign" or "number sign"). Comment lines are ignored by
 
165
Bazaar when parsing ini files.
 
166
 
 
167
Section headers
 
168
^^^^^^^^^^^^^^^
 
169
 
 
170
A section header is a word enclosed in brackets that starts at the begining
 
171
of a line.  A typical section header looks like this::
 
172
 
 
173
    [DEFAULT]
 
174
 
 
175
The only valid section headers for bazaar.conf currently are [DEFAULT] and
 
176
[ALIASES].  Section headers are case sensitive. The default section provides for
 
177
setting variables which can be overridden with the branch config file.
 
178
 
 
179
For ``locations.conf``, the variables from the section with the
 
180
longest matching section header are used to the exclusion of other
 
181
potentially valid section headers. A section header uses the path for
 
182
the branch as the section header. Some examples include::
 
183
 
 
184
    [http://mybranches.isp.com/~jdoe/branchdir]
 
185
    [/home/jdoe/branches/]
 
186
 
 
187
 
 
188
Section variables
 
189
^^^^^^^^^^^^^^^^^
 
190
 
 
191
A section variable resides within a section. A section variable contains a
 
192
variable name, an equals sign and a value.  For example::
 
193
 
 
194
    email            = John Doe <jdoe@isp.com>
 
195
    check_signatures = require
 
196
 
 
197
 
 
198
Variable policies
 
199
^^^^^^^^^^^^^^^^^
 
200
 
 
201
Variables defined in a section affect the named directory or URL plus
 
202
any locations they contain.  Policies can be used to change how a
 
203
variable value is interpreted for contained locations.  Currently
 
204
there are three policies available:
 
205
 
 
206
 none:
 
207
   the value is interpreted the same for contained locations.  This is
 
208
   the default behaviour.
 
209
 norecurse:
 
210
   the value is only used for the exact location specified by the
 
211
   section name.
 
212
 appendpath:
 
213
   for contained locations, any additional path components are
 
214
   appended to the value.
 
215
 
 
216
Policies are specified by keys with names of the form "$var:policy".
 
217
For example, to define the push location for a tree of branches, the
 
218
following could be used::
 
219
 
 
220
  [/top/location]
 
221
  push_location = sftp://example.com/location
 
222
  push_location:policy = appendpath
 
223
 
 
224
With this configuration, the push location for ``/top/location/branch1``
 
225
would be ``sftp://example.com/location/branch1``.
 
226
 
 
227
 
 
228
The main configuration file, bazaar.conf
 
229
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
230
 
 
231
``bazaar.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
 
232
The default section contains the default
 
233
configuration options for all branches. The default section can be
 
234
overriden by providing a branch-specific section in ``locations.conf``.
 
235
 
 
236
A typical ``bazaar.conf`` section often looks like the following::
 
237
 
 
238
    [DEFAULT]
 
239
    email             = John Doe <jdoe@isp.com>
 
240
    editor            = /usr/bin/vim
 
241
    check_signatures  = check-available
 
242
    create_signatures = when-required
 
243
 
 
244
 
 
245
The branch location configuration file, locations.conf
 
246
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
247
 
 
248
``locations.conf`` allows one to specify overriding settings for
 
249
a specific branch. The format is almost identical to the default section in
 
250
bazaar.conf with one significant change: The section header, instead of saying
 
251
default, will be the path to a branch that you wish to override a value
 
252
for. The '?' and '*' wildcards are supported::
 
253
 
 
254
    [/home/jdoe/branches/nethack]
 
255
    email = Nethack Admin <nethack@nethack.com>
 
256
 
 
257
    [http://hypothetical.site.com/branches/devel-branch]
 
258
    create_signatures = always
 
259
    check_signatures  = always
 
260
 
 
261
    [http://bazaar-vcs.org/bzr/*]
 
262
    check_signatures  = require
 
263
 
 
264
The authentication configuration file, authentication.conf
 
265
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
266
 
 
267
``authentication.conf`` allows one to specify credentials for
 
268
remote servers. This can be used for all the supported transports and any part
 
269
of bzr that requires authentication (smtp for example).
 
270
 
 
271
The syntax of the file obeys the same rules as the others except for the
 
272
variable policies which don't apply.
 
273
 
 
274
For more information on the possible uses of the authentication configuration
 
275
file see :doc:`authentication-help`.
 
276
 
 
277
 
 
278
Common variable options
 
279
-----------------------
 
280
 
 
281
debug_flags
 
282
~~~~~~~~~~~
 
283
 
 
284
A comma-separated list of debugging options to turn on.  The same values
 
285
can be used as with the -D command-line option (see `help global-options`).
 
286
For example::
 
287
 
 
288
    debug_flags = hpss
 
289
 
 
290
email
 
291
~~~~~
 
292
 
 
293
The email address to use when committing a branch. Typically takes the form
 
294
of::
 
295
 
 
296
    email = Full Name <account@hostname.tld>
 
297
 
 
298
editor
 
299
~~~~~~
 
300
 
 
301
The path of the editor that you wish to use if *bzr commit* is run without
 
302
a commit message. This setting is trumped by the environment variable
 
303
``BZR_EDITOR``, and overrides the ``VISUAL`` and ``EDITOR`` environment
 
304
variables.
 
305
 
 
306
log_format
 
307
~~~~~~~~~~
 
308
 
 
309
The default log format to use. Standard log formats are ``long``, ``short``
 
310
and ``line``. Additional formats may be provided by plugins. The default
 
311
value is ``long``.
 
312
 
 
313
check_signatures
 
314
~~~~~~~~~~~~~~~~
 
315
 
 
316
Defines the behavior for signatures.
 
317
 
 
318
require
 
319
    The gnupg signature for revisions must be present and must be valid.
 
320
 
 
321
ignore
 
322
    Do not check gnupg signatures of revisions.
 
323
 
 
324
check-available
 
325
    (default) If gnupg signatures for revisions are present, check them.
 
326
    Bazaar will fail if it finds a bad signature, but will not fail if
 
327
    no signature is present.
 
328
 
 
329
create_signatures
 
330
~~~~~~~~~~~~~~~~~
 
331
 
 
332
Defines the behaviour of signing revisions.
 
333
 
 
334
always
 
335
    Sign every new revision that is committed.
 
336
 
 
337
when-required
 
338
    (default) Sign newly committed revisions only when the branch requires
 
339
    signed revisions.
 
340
 
 
341
never
 
342
    Refuse to sign newly committed revisions, even if the branch
 
343
    requires signatures.
 
344
 
 
345
recurse
 
346
~~~~~~~
 
347
 
 
348
Only useful in ``locations.conf``. Defines whether or not the
 
349
configuration for this section applies to subdirectories:
 
350
 
 
351
true
 
352
    (default) This section applies to subdirectories as well.
 
353
 
 
354
false
 
355
    This section only applies to the branch at this directory and not
 
356
    branches below it.
 
357
 
 
358
gpg_signing_command
 
359
~~~~~~~~~~~~~~~~~~~
 
360
 
 
361
(Default: "gpg"). Which program should be used to sign and check revisions.
 
362
For example::
 
363
 
 
364
    gpg_signing_command = /usr/bin/gnpg
 
365
 
 
366
bzr_remote_path
 
367
~~~~~~~~~~~~~~~
 
368
 
 
369
(Default: "bzr").  The path to the command that should be used to run the smart
 
370
server for bzr.  This value may only be specified in locations.conf, because:
 
371
 
 
372
- it's needed before branch.conf is accessible
 
373
- allowing remote branch.conf files to specify commands would be a security
 
374
  risk
 
375
 
 
376
It is overridden by the BZR_REMOTE_PATH environment variable.
 
377
 
 
378
smtp_server
 
379
~~~~~~~~~~~
 
380
 
 
381
(Default: "localhost"). SMTP server to use when Bazaar needs to send
 
382
email, eg. with ``merge-directive --mail-to``, or the bzr-email plugin.
 
383
 
 
384
smtp_username, smtp_password
 
385
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
386
 
 
387
User and password to authenticate to the SMTP server. If smtp_username
 
388
is set, and smtp_password is not, Bazaar will prompt for a password.
 
389
These settings are only needed if the SMTP server requires authentication
 
390
to send mail.
 
391
 
 
392
mail_client
 
393
~~~~~~~~~~~
 
394
 
 
395
A mail client to use for sending merge requests.
 
396
By default, bzr will try to use ``mapi`` on Windows.  On other platforms, it
 
397
will try ``xdg-email``. If either of these fails, it will fall back to
 
398
``editor``.
 
399
 
 
400
Supported values for specific clients:
 
401
 
 
402
:claws: Use Claws.  This skips a dialog for attaching files.
 
403
:evolution: Use Evolution.
 
404
:kmail: Use KMail.
 
405
:mutt: Use Mutt.
 
406
:thunderbird: Use Mozilla Thunderbird or Icedove.  For Thunderbird/Icedove 1.5,
 
407
    this works around some bugs that xdg-email doesn't handle.
 
408
 
 
409
Supported generic values are:
 
410
 
 
411
:default: See above.
 
412
:editor: Use your editor to compose the merge request.  This also uses
 
413
    your commit id, (see ``bzr whoami``), smtp_server and (optionally)
 
414
    smtp_username and smtp_password.
 
415
:mapi: Use your preferred e-mail client on Windows.
 
416
:xdg-email: Use xdg-email to run your preferred mail program
 
417
 
 
418
submit_branch
 
419
~~~~~~~~~~~~~
 
420
 
 
421
The branch you intend to submit your current work to.  This is automatically
 
422
set by ``bzr send``, and is also used by the ``submit:`` revision spec.  This
 
423
should usually be set on a per-branch or per-location basis.
 
424
 
 
425
public_branch
 
426
~~~~~~~~~~~~~
 
427
 
 
428
A publically-accessible version of this branch (implying that this version is
 
429
not publically-accessible).  Used (and set) by ``bzr send``.
 
430
 
 
431
suppress_warnings
 
432
~~~~~~~~~~~~~~~~~
 
433
 
 
434
A list of strings, each string represent a warning that can be emitted by
 
435
bzr. Mentioning a warning in this list tells bzr to not emit it.
 
436
 
 
437
Valid values:
 
438
 
 
439
* ``format_deprecation``:
 
440
    whether the format deprecation warning is shown on repositories that are
 
441
    using deprecated formats.
 
442
 
 
443
 
 
444
Branch type specific options
 
445
----------------------------
 
446
 
 
447
These options apply only to branches that use the ``dirstate-tags`` or
 
448
later format.  They
 
449
are usually set in ``.bzr/branch/branch.conf`` automatically, but may be
 
450
manually set in ``locations.conf`` or ``bazaar.conf``.
 
451
 
 
452
append_revisions_only
 
453
~~~~~~~~~~~~~~~~~~~~~
 
454
 
 
455
If set to "True" then revisions can only be appended to the log, not
 
456
removed.  A branch with this setting enabled can only pull from
 
457
another branch if the other branch's log is a longer version of its
 
458
own.  This is normally set by ``bzr init --append-revisions-only``.
 
459
 
 
460
parent_location
 
461
~~~~~~~~~~~~~~~
 
462
 
 
463
If present, the location of the default branch for pull or merge.
 
464
This option is normally set by ``pull --remember`` or ``merge
 
465
--remember``.
 
466
 
 
467
push_location
 
468
~~~~~~~~~~~~~
 
469
 
 
470
If present, the location of the default branch for push.  This option
 
471
is normally set by ``push --remember``.
 
472
 
 
473
push_strict
 
474
~~~~~~~~~~~
 
475
 
 
476
If present, defines the ``--strict`` option default value for checking
 
477
uncommitted changes before pushing.
 
478
 
 
479
dpush_strict
 
480
~~~~~~~~~~~~
 
481
 
 
482
If present, defines the ``--strict`` option default value for checking
 
483
uncommitted changes before pushing into a different VCS without any
 
484
custom bzr metadata.
 
485
 
 
486
bound_location
 
487
~~~~~~~~~~~~~~
 
488
 
 
489
The location that commits should go to when acting as a checkout.
 
490
This option is normally set by ``bind``.
 
491
 
 
492
bound
 
493
~~~~~
 
494
 
 
495
If set to "True", the branch should act as a checkout, and push each commit to
 
496
the bound_location.  This option is normally set by ``bind``/``unbind``.
 
497
 
 
498
send_strict
 
499
~~~~~~~~~~~
 
500
 
 
501
If present, defines the ``--strict`` option default value for checking
 
502
uncommitted changes before sending a merge directive.
 
503