/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

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

  • Committer: Martin Pool
  • Date: 2009-07-27 06:28:35 UTC
  • mto: This revision was merged to the branch mainline in revision 4587.
  • Revision ID: mbp@sourcefrog.net-20090727062835-o66p8it658tq1sma
Add CountedLock.get_physical_lock_status

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/help_topics/en/configuration.txt
7
7
While most configuration is handled by configuration files, some options
8
8
which may be semi-permanent can also be controlled through the environment.
9
9
 
10
 
BRZ_EMAIL
 
10
BZR_EMAIL
11
11
~~~~~~~~~
12
12
 
13
 
Override the email id used by Breezy.  Typical format::
 
13
Override the email id used by Bazaar.  Typical format::
14
14
 
15
15
  "John Doe <jdoe@example.com>"
16
16
 
17
 
See also the ``email`` configuration option.
 
17
See also the ``email`` configuration value.
18
18
 
19
 
BRZ_PROGRESS_BAR
 
19
BZR_PROGRESS_BAR
20
20
~~~~~~~~~~~~~~~~
21
21
 
22
 
Override the progress display.  Possible values are "none" or "text".  If
23
 
the value is "none" then no progress bar is displayed.  The value "text" draws
24
 
the ordinary command line progress bar.
 
22
Override the progress display.  Possible values are "none", "dots", "tty"
25
23
 
26
 
BRZ_SIGQUIT_PDB
 
24
BZR_SIGQUIT_PDB
27
25
~~~~~~~~~~~~~~~
28
26
 
29
27
Control whether SIGQUIT behaves normally or invokes a breakin debugger.
31
29
* 0 = Standard SIGQUIT behavior (normally, exit with a core dump)
32
30
* 1 = Invoke breakin debugger (default)
33
31
 
34
 
BRZ_HOME
 
32
BZR_HOME
35
33
~~~~~~~~
36
34
 
37
 
Override the home directory used by Breezy.
 
35
Override the home directory used by Bazaar.
38
36
 
39
 
BRZ_SSH
 
37
BZR_SSH
40
38
~~~~~~~
41
39
 
42
40
Select a different SSH implementation.
43
41
 
44
 
BRZ_PDB
 
42
BZR_PDB
45
43
~~~~~~~
46
44
 
47
45
Control whether to launch a debugger on error.
52
50
BZR_REMOTE_PATH
53
51
~~~~~~~~~~~~~~~
54
52
 
55
 
Path to the Bazaar or Breezy executable to use when using the bzr+ssh protocol.
56
 
 
57
 
See also the ``bzr_remote_path`` configuration option.
58
 
 
59
 
BRZ_EDITOR
 
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
60
58
~~~~~~~~~~
61
59
 
62
 
Path to the editor Breezy should use for commit messages, etc.
63
 
 
64
 
BRZ_LOG
65
 
~~~~~~~
66
 
 
67
 
Location of the Breezy log file. You can check the current location by
68
 
running ``bzr version``.
69
 
 
70
 
The log file contains debug information that is useful for diagnosing or
71
 
reporting problems with Breezy.
72
 
 
73
 
Setting this to ``NUL`` on Windows or ``/dev/null`` on other platforms
74
 
will disable logging.
75
 
 
76
 
 
77
 
BRZ_PLUGIN_PATH
 
60
Path to the editor Bazaar should use for commit messages, etc.
 
61
 
 
62
BZR_PLUGIN_PATH
78
63
~~~~~~~~~~~~~~~
79
64
 
80
 
The path to the plugins directory that Breezy should use.
81
 
If not set, Breezy will search for plugins in:
82
 
 
83
 
* the user specific plugin directory (containing the ``user`` plugins),
84
 
 
85
 
* the breezy directory (containing the ``core`` plugins),
86
 
 
87
 
* the site specific plugin directory if applicable (containing
88
 
  the ``site`` plugins).
89
 
 
90
 
If ``BZR_PLUGIN_PATH`` is set in any fashion, it will change the
91
 
the way the plugin are searched. 
92
 
 
93
 
As for the ``PATH`` variables, if multiple directories are
94
 
specified in ``BZR_PLUGIN_PATH`` they should be separated by the
95
 
platform specific appropriate character (':' on Unix,
96
 
';' on windows)
97
 
 
98
 
By default if ``BZR_PLUGIN_PATH`` is set, it replaces searching
99
 
in ``user``.  However it will continue to search in ``core`` and
100
 
``site`` unless they are explicitly removed.
101
 
 
102
 
If you need to change the order or remove one of these
103
 
directories, you should use special values:
104
 
 
105
 
* ``-user``, ``-core``, ``-site`` will remove the corresponding
106
 
  path from the default values,
107
 
 
108
 
* ``+user``, ``+core``, ``+site`` will add the corresponding path
109
 
  before the remaining default values (and also remove it from
110
 
  the default values).
111
 
 
112
 
Note that the special values 'user', 'core' and 'site' should be
113
 
used literally, they will be substituted by the corresponding,
114
 
platform specific, values.
115
 
 
116
 
The examples below use ':' as the separator, windows users
117
 
should use ';'.
118
 
 
119
 
Overriding the default user plugin directory::
120
 
 
121
 
  BZR_PLUGIN_PATH='/path/to/my/other/plugins'
122
 
 
123
 
Disabling the site directory while retaining the user directory::
124
 
 
125
 
  BZR_PLUGIN_PATH='-site:+user'
126
 
 
127
 
Disabling all plugins (better achieved with --no-plugins)::
128
 
 
129
 
  BZR_PLUGIN_PATH='-user:-core:-site'
130
 
 
131
 
Overriding the default site plugin directory::
132
 
 
133
 
  BZR_PLUGIN_PATH='/path/to/my/site/plugins:-site':+user
134
 
 
135
 
BRZ_DISABLE_PLUGINS
136
 
~~~~~~~~~~~~~~~~~~~
137
 
 
138
 
Under special circumstances (mostly when trying to diagnose a
139
 
bug), it's better to disable a plugin (or several) rather than
140
 
uninstalling them completely. Such plugins can be specified in
141
 
the ``BZR_DISABLE_PLUGINS`` environment variable.
142
 
 
143
 
In that case, ``bzr`` will stop loading the specified plugins and
144
 
will raise an import error if they are explicitly imported (by
145
 
another plugin that depends on them for example).
146
 
 
147
 
Disabling ``myplugin`` and ``yourplugin`` is achieved by::
148
 
 
149
 
  BZR_DISABLE_PLUGINS='myplugin:yourplugin'
150
 
 
151
 
BRZ_PLUGINS_AT
152
 
~~~~~~~~~~~~~~
153
 
 
154
 
When adding a new feature or working on a bug in a plugin,
155
 
developers often need to use a specific version of a given
156
 
plugin. Since python requires that the directory containing the
157
 
code is named like the plugin itself this make it impossible to
158
 
use arbitrary directory names (using a two-level directory scheme
159
 
is inconvenient). ``BZR_PLUGINS_AT`` allows such directories even
160
 
if they don't appear in ``BZR_PLUGIN_PATH`` .
161
 
 
162
 
Plugins specified in this environment variable takes precedence
163
 
over the ones in ``BZR_PLUGIN_PATH``.
164
 
 
165
 
The variable specified a list of ``plugin_name@plugin path``,
166
 
``plugin_name`` being the name of the plugin as it appears in
167
 
python module paths, ``plugin_path`` being the path to the
168
 
directory containing the plugin code itself
169
 
(i.e. ``plugins/myplugin`` not ``plugins``).  Use ':' as the list
170
 
separator, use ';' on windows.
171
 
 
172
 
Example:
173
 
~~~~~~~~
174
 
 
175
 
Using a specific version of ``myplugin``:
176
 
``BZR_PLUGINS_AT='myplugin@/home/me/bugfixes/123456-myplugin``
177
 
 
178
 
BRZPATH
 
65
The path to the plugins directory that Bazaar should use.
 
66
 
 
67
BZRPATH
179
68
~~~~~~~
180
69
 
181
 
The path where Breezy should look for shell plugin external commands.
182
 
 
183
 
 
184
 
http_proxy, https_proxy
185
 
~~~~~~~~~~~~~~~~~~~~~~~
186
 
 
187
 
Specifies the network proxy for outgoing connections, for example::
188
 
 
189
 
  http_proxy=http://proxy.example.com:3128/ 
190
 
  https_proxy=http://proxy.example.com:3128/
 
70
The path where Bazaar should look for shell plugin external commands.
191
71
 
192
72
 
193
73
Configuration files
196
76
Location
197
77
~~~~~~~~
198
78
 
199
 
Configuration files are located in ``$HOME/.bazaar`` on Unix and
200
 
``C:\Documents and Settings\<username>\Application Data\Breezy\2.0`` on
 
79
Configuration files are located in ``$HOME/.bazaar`` on Linux/Unix and
 
80
``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` on
201
81
Windows. (You can check the location for your system by using
202
82
``bzr version``.)
203
83
 
204
84
There are three primary configuration files in this location:
205
85
 
206
 
* ``breezy.conf`` describes default configuration options,
 
86
* ``bazaar.conf`` describes default configuration options,
207
87
 
208
88
* ``locations.conf`` describes configuration information for
209
89
  specific branch locations,
221
101
~~~~~~~~~~~~~~
222
102
 
223
103
An ini file has three types of contructs: section headers, section
224
 
options and comments.
 
104
variables and comments.
225
105
 
226
106
Comments
227
107
^^^^^^^^
228
108
 
229
109
A comment is any line that starts with a "#" (sometimes called a "hash
230
110
mark", "pound sign" or "number sign"). Comment lines are ignored by
231
 
Breezy when parsing ini files.
 
111
Bazaar when parsing ini files.
232
112
 
233
113
Section headers
234
114
^^^^^^^^^^^^^^^
238
118
 
239
119
    [DEFAULT]
240
120
 
241
 
The only valid section headers for breezy.conf currently are [DEFAULT] and
 
121
The only valid section headers for bazaar.conf currently are [DEFAULT] and
242
122
[ALIASES].  Section headers are case sensitive. The default section provides for
243
 
setting options which can be overridden with the branch config file.
 
123
setting variables which can be overridden with the branch config file.
244
124
 
245
 
For ``locations.conf``, the options from the section with the
 
125
For ``locations.conf``, the variables from the section with the
246
126
longest matching section header are used to the exclusion of other
247
127
potentially valid section headers. A section header uses the path for
248
128
the branch as the section header. Some examples include::
251
131
    [/home/jdoe/branches/]
252
132
 
253
133
 
254
 
Section options
255
 
^^^^^^^^^^^^^^^
 
134
Section variables
 
135
^^^^^^^^^^^^^^^^^
256
136
 
257
 
A section option resides within a section. A section option contains an
258
 
option name, an equals sign and a value.  For example::
 
137
A section variable resides within a section. A section variable contains a
 
138
variable name, an equals sign and a value.  For example::
259
139
 
260
140
    email            = John Doe <jdoe@isp.com>
261
 
    gpg_signing_key  = Amy Pond <amy@example.com>
262
 
 
263
 
A option can reference other options by enclosing them in curly brackets::
264
 
 
265
 
    my_branch_name = feature_x
266
 
    my_server      = bzr+ssh://example.com
267
 
    push_location   = {my_server}/project/{my_branch_name}
268
 
 
269
 
Option policies
270
 
^^^^^^^^^^^^^^^
271
 
 
272
 
Options defined in a section affect the named directory or URL plus
273
 
any locations they contain.  Policies can be used to change how an
274
 
option value is interpreted for contained locations.  Currently
 
141
    check_signatures = require
 
142
 
 
143
 
 
144
Variable policies
 
145
^^^^^^^^^^^^^^^^^
 
146
 
 
147
Variables defined in a section affect the named directory or URL plus
 
148
any locations they contain.  Policies can be used to change how a
 
149
variable value is interpreted for contained locations.  Currently
275
150
there are three policies available:
276
151
 
277
152
 none:
284
159
   for contained locations, any additional path components are
285
160
   appended to the value.
286
161
 
287
 
Policies are specified by keys with names of the form "<option_name>:policy".
 
162
Policies are specified by keys with names of the form "$var:policy".
288
163
For example, to define the push location for a tree of branches, the
289
164
following could be used::
290
165
 
295
170
With this configuration, the push location for ``/top/location/branch1``
296
171
would be ``sftp://example.com/location/branch1``.
297
172
 
298
 
Section local options
299
 
^^^^^^^^^^^^^^^^^^^^^
300
 
 
301
 
Some options are defined automatically inside a given section and can be
302
 
refered to in this section only. 
303
 
 
304
 
For example, the ``appendpath`` policy can be used like this::
305
 
 
306
 
  [/home/vila/src/bzr/bugs]
307
 
  mypush = lp:~vila/bzr
308
 
  mypush:policy=appendpath
309
 
 
310
 
Using ``relpath`` to achieve the same result is done like this::
311
 
 
312
 
  [/home/vila/src/bzr/bugs]
313
 
  mypush = lp:~vila/bzr/{relpath}
314
 
 
315
 
In both cases, when used in a directory like
316
 
``/home/vila/src/bzr/bugs/832013-expand-in-stack`` we'll get::
317
 
 
318
 
   $ bzr config mypush
319
 
   lp:~vila/bzr/832013-expand-in-stack
320
 
 
321
 
Another such option is ``basename`` which can be used like this::
322
 
 
323
 
  [/home/vila/src/bzr]
324
 
  mypush = lp:~vila/bzr/{basename}
325
 
 
326
 
When used in a directory like
327
 
``/home/vila/src/bzr/bugs/832013-expand-in-stack`` we'll get::
328
 
 
329
 
   $ bzr config mypush
330
 
   lp:~vila/bzr/832013-expand-in-stack
331
 
 
332
 
Note that ``basename`` here refers to the base name of ``relpath`` which
333
 
itself is defined as the relative path between the section name and the
334
 
location it matches.
335
 
 
336
 
Another such option is ``branchname``, which refers to the name of a colocated
337
 
branch.  For non-colocated branches, it behaves like basename.  It can be used
338
 
like this::
339
 
 
340
 
  [/home/vila/src/bzr/bugs]
341
 
  mypush = lp:~vila/bzr/{branchname}
342
 
 
343
 
When used with a colocated branch named ``832013-expand-in-stack``, we'll get::
344
 
 
345
 
  bzr config mypush
346
 
  lp:~vila/bzr/832013-expand-in-stack
347
 
 
348
 
When an option is local to a Section, it cannot be referred to from option
349
 
values in any other section from the same ``Store`` nor from any other
350
 
``Store``.
351
 
 
352
 
 
353
 
The main configuration file, breezy.conf
 
173
 
 
174
The main configuration file, bazaar.conf
354
175
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
355
176
 
356
 
``breezy.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
 
177
``bazaar.conf`` allows two sections: ``[DEFAULT]`` and ``[ALIASES]``.
357
178
The default section contains the default
358
179
configuration options for all branches. The default section can be
359
180
overriden by providing a branch-specific section in ``locations.conf``.
360
181
 
361
 
A typical ``breezy.conf`` section often looks like the following::
 
182
A typical ``bazaar.conf`` section often looks like the following::
362
183
 
363
184
    [DEFAULT]
364
185
    email             = John Doe <jdoe@isp.com>
365
186
    editor            = /usr/bin/vim
 
187
    check_signatures  = check-available
366
188
    create_signatures = when-required
367
189
 
368
190
 
371
193
 
372
194
``locations.conf`` allows one to specify overriding settings for
373
195
a specific branch. The format is almost identical to the default section in
374
 
breezy.conf with one significant change: The section header, instead of saying
 
196
bazaar.conf with one significant change: The section header, instead of saying
375
197
default, will be the path to a branch that you wish to override a value
376
198
for. The '?' and '*' wildcards are supported::
377
199
 
380
202
 
381
203
    [http://hypothetical.site.com/branches/devel-branch]
382
204
    create_signatures = always
 
205
    check_signatures  = always
 
206
 
 
207
    [http://bazaar-vcs.org/bzr/*]
 
208
    check_signatures  = require
383
209
 
384
210
The authentication configuration file, authentication.conf
385
211
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
389
215
of bzr that requires authentication (smtp for example).
390
216
 
391
217
The syntax of the file obeys the same rules as the others except for the
392
 
option policies which don't apply.
 
218
variable policies which don't apply.
393
219
 
394
220
For more information on the possible uses of the authentication configuration
395
 
file see :doc:`authentication-help`.
396
 
 
397
 
 
398
 
Common options
399
 
--------------
 
221
file see `Authentication Settings`_.
 
222
 
 
223
 
 
224
Common variable options
 
225
-----------------------
400
226
 
401
227
debug_flags
402
228
~~~~~~~~~~~
407
233
 
408
234
    debug_flags = hpss
409
235
 
410
 
or::
411
 
 
412
 
    debug_flags = hpss,evil
413
 
 
414
236
email
415
237
~~~~~
416
238
 
437
259
check_signatures
438
260
~~~~~~~~~~~~~~~~
439
261
 
440
 
Reserved for future use.  These options will allow a policy for branches to
441
 
require signatures.
 
262
Defines the behavior for signatures.
442
263
 
443
264
require
444
265
    The gnupg signature for revisions must be present and must be valid.
448
269
 
449
270
check-available
450
271
    (default) If gnupg signatures for revisions are present, check them.
451
 
    Breezy will fail if it finds a bad signature, but will not fail if
 
272
    Bazaar will fail if it finds a bad signature, but will not fail if
452
273
    no signature is present.
453
274
 
454
275
create_signatures
455
276
~~~~~~~~~~~~~~~~~
456
277
 
457
 
Defines the behaviour of signing revisions on commits.  By default bzr will not
458
 
sign new commits.
 
278
Defines the behaviour of signing revisions.
459
279
 
460
280
always
461
 
    Sign every new revision that is committed.  If the signing fails then the
462
 
    commit will not be made.
 
281
    Sign every new revision that is committed.
463
282
 
464
283
when-required
465
 
    Reserved for future use.
 
284
    (default) Sign newly committed revisions only when the branch requires
 
285
    signed revisions.
466
286
 
467
287
never
468
 
    Reserved for future use.
469
 
 
470
 
In future it is planned that ``when-required`` will sign newly
471
 
committed revisions only when the branch requires them.  ``never`` will refuse
472
 
to sign newly committed revisions, even if the branch requires signatures.
473
 
 
474
 
dirstate.fdatasync
475
 
~~~~~~~~~~~~~~~~~~
476
 
 
477
 
If true (default), working tree metadata changes are flushed through the
478
 
OS buffers to physical disk.  This is somewhat slower, but means data
479
 
should not be lost if the machine crashes.  See also repository.fdatasync.
480
 
 
481
 
gpg_signing_key
482
 
~~~~~~~~~~~~~~~
483
 
 
484
 
The GnuPG user identity to use when signing commits.  Can be an e-mail
485
 
address, key fingerprint or full key ID.  When unset or when set to
486
 
"default" Breezy will use the user e-mail set with ``whoami``.
 
288
    Refuse to sign newly committed revisions, even if the branch
 
289
    requires signatures.
487
290
 
488
291
recurse
489
292
~~~~~~~
498
301
    This section only applies to the branch at this directory and not
499
302
    branches below it.
500
303
 
 
304
gpg_signing_command
 
305
~~~~~~~~~~~~~~~~~~~
 
306
 
 
307
(Default: "gpg"). Which program should be used to sign and check revisions.
 
308
For example::
 
309
 
 
310
    gpg_signing_command = /usr/bin/gnpg
 
311
 
501
312
bzr_remote_path
502
313
~~~~~~~~~~~~~~~
503
314
 
513
324
smtp_server
514
325
~~~~~~~~~~~
515
326
 
516
 
(Default: "localhost"). SMTP server to use when Breezy needs to send
 
327
(Default: "localhost"). SMTP server to use when Bazaar needs to send
517
328
email, eg. with ``merge-directive --mail-to``, or the bzr-email plugin.
518
329
 
519
330
smtp_username, smtp_password
520
331
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
521
332
 
522
333
User and password to authenticate to the SMTP server. If smtp_username
523
 
is set, and smtp_password is not, Breezy will prompt for a password.
 
334
is set, and smtp_password is not, Bazaar will prompt for a password.
524
335
These settings are only needed if the SMTP server requires authentication
525
336
to send mail.
526
337
 
527
 
locks.steal_dead
528
 
~~~~~~~~~~~~~~~~
529
 
 
530
 
By default, bzr will automatically break locks held by processes from
531
 
the same machine and user that are no longer alive.  If disabled, it will
532
 
print a message and you can break the lock manually, if you are satisfied
533
 
the object is no longer in use.
534
 
 
535
338
mail_client
536
339
~~~~~~~~~~~
537
340
 
558
361
:mapi: Use your preferred e-mail client on Windows.
559
362
:xdg-email: Use xdg-email to run your preferred mail program
560
363
 
561
 
repository.fdatasync
562
 
~~~~~~~~~~~~~~~~~~~~
563
 
 
564
 
If true (default), repository changes are flushed through the OS buffers
565
 
to physical disk.  This is somewhat slower, but means data should not be
566
 
lost if the machine crashes.  See also dirstate.fdatasync.
567
 
 
568
364
submit_branch
569
365
~~~~~~~~~~~~~
570
366
 
578
374
A publically-accessible version of this branch (implying that this version is
579
375
not publically-accessible).  Used (and set) by ``bzr send``.
580
376
 
581
 
suppress_warnings
582
 
~~~~~~~~~~~~~~~~~
583
 
 
584
 
A list of strings, each string represent a warning that can be emitted by
585
 
bzr. Mentioning a warning in this list tells bzr to not emit it.
586
 
 
587
 
Valid values:
588
 
 
589
 
* ``format_deprecation``:
590
 
    whether the format deprecation warning is shown on repositories that are
591
 
    using deprecated formats.
592
 
 
593
 
* ``insecure_permissions``:
594
 
    whether a warning is shown if ``authentication.conf`` can be read
595
 
    by other users.
596
 
 
597
 
default_format
598
 
~~~~~~~~~~~~~~
599
 
 
600
 
A format name for the default format used when creating branches.  See ``bzr
601
 
help formats`` for possible values.
602
 
 
603
 
 
604
 
Unicode options
605
 
---------------
606
 
 
607
 
output_encoding
608
 
~~~~~~~~~~~~~~~
609
 
 
610
 
A Python unicode encoding name for text output from bzr, such as log
611
 
information.  Values include: utf8, cp850, ascii, iso-8859-1.  The default
612
 
is the terminal encoding prefered by the operating system.
613
 
 
614
377
 
615
378
Branch type specific options
616
379
----------------------------
618
381
These options apply only to branches that use the ``dirstate-tags`` or
619
382
later format.  They
620
383
are usually set in ``.bzr/branch/branch.conf`` automatically, but may be
621
 
manually set in ``locations.conf`` or ``breezy.conf``.
 
384
manually set in ``locations.conf`` or ``bazaar.conf``.
622
385
 
623
386
append_revisions_only
624
387
~~~~~~~~~~~~~~~~~~~~~
625
388
 
626
389
If set to "True" then revisions can only be appended to the log, not
627
 
removed.  A branch with this setting enabled can only pull from another
628
 
branch if the other branch's log is a longer version of its own.  This is
629
 
normally set by ``bzr init --append-revisions-only``. If you set it
630
 
manually, use either 'True' or 'False' (case-sensitive) to maintain
631
 
compatibility with previous bzr versions (older than 2.2).
 
390
removed.  A branch with this setting enabled can only pull from
 
391
another branch if the other branch's log is a longer version of its
 
392
own.  This is normally set by ``bzr init --append-revisions-only``.
632
393
 
633
394
parent_location
634
395
~~~~~~~~~~~~~~~
635
396
 
636
 
If present, the location of the default branch for pull or merge.  This option
637
 
is normally set when creating a branch, the first ``pull`` or by ``pull
 
397
If present, the location of the default branch for pull or merge.
 
398
This option is normally set by ``pull --remember`` or ``merge
638
399
--remember``.
639
400
 
640
401
push_location
641
402
~~~~~~~~~~~~~
642
403
 
643
404
If present, the location of the default branch for push.  This option
644
 
is normally set by the first ``push`` or ``push --remember``.
 
405
is normally set by ``push --remember``.
645
406
 
646
407
push_strict
647
408
~~~~~~~~~~~
667
428
If present, defines the ``--strict`` option default value for checking
668
429
uncommitted changes before sending a merge directive.
669
430
 
670
 
add.maximum_file_size
671
 
~~~~~~~~~~~~~~~~~~~~~
672
 
 
673
 
Defines the maximum file size the command line "add" operation will allow
674
 
in recursive mode, with files larger than this value being skipped. You may 
675
 
specify this value as an integer (in which case it is interpreted as bytes), 
676
 
or you may specify the value using SI units, i.e. 10KB, 20MB, 1G. A value of 0 
677
 
will disable skipping.
678
 
 
679
 
External Merge Tools
680
 
--------------------
681
 
 
682
 
bzr.mergetool.<name>
683
 
~~~~~~~~~~~~~~~~~~~~
684
 
 
685
 
Defines an external merge tool called <name> with the given command-line.
686
 
Arguments containing spaces should be quoted using single or double quotes. The
687
 
executable may omit its path if it can be found on the PATH.
688
 
 
689
 
The following markers can be used in the command-line to substitute filenames
690
 
involved in the merge conflict::
691
 
 
692
 
  {base}      file.BASE
693
 
  {this}      file.THIS
694
 
  {other}     file.OTHER
695
 
  {result}    output file
696
 
  {this_temp} temp copy of file.THIS, used to overwrite output file if merge
697
 
              succeeds.
698
 
 
699
 
For example::
700
 
 
701
 
  bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
702
 
 
703
 
Because ``mergetool`` and ``config`` itself both use curly braces as
704
 
interpolation markers, trying to display the mergetool line results in the
705
 
following problem::
706
 
 
707
 
 
708
 
  $ bzr config bzr.mergetool.kdiff3='kdiff3 {base} {this} {other} -o {result}'
709
 
  $ bzr config bzr.mergetool.kdiff3
710
 
  bzr: ERROR: Option base is not defined while expanding "kdiff3 {base} {this} {other} -o {result}".
711
 
 
712
 
To avoid this, ``config`` can be instructed not to try expanding variables::
713
 
 
714
 
  $ bzr config --all bzr.mergetool.kdiff3
715
 
  branch:
716
 
    bzr.mergetool.kdiff3 = kdiff3 {base} {this} {other} -o {result}
717
 
 
718
 
 
719
 
bzr.default_mergetool
720
 
~~~~~~~~~~~~~~~~~~~~~
721
 
 
722
 
Specifies which external merge tool (as defined above) should be selected by
723
 
default in tools such as ``bzr qconflicts``.
724
 
 
725
 
For example::
726
 
 
727
 
  bzr.default_mergetool = kdiff3