WorkingTree.wt.get_config_stack and BzrDirConfig

Aaron Bentley aaron at
Thu Feb 16 16:09:15 UTC 2012

Hash: SHA1

Before gettting into this, I think that I may have misunderstood your
plan.  I think of there being branch-specific configuration values,
tree-specific configuration values and repository-specific
configuration values.  I assumed that branch.conf would only carry
branch-specific configuration values, tree.conf would only carry
tree-specific configuration values, and repository.conf would only
carry repository-specific configuration values.

> There are use cases (and bugs) where bzr users have asked for,
> say, being able to set an email per-working tree
> ( and setting this in 'control.conf' will also
> apply to the branch or the repository, defeating the user intent.

To expand your example, we have standalone tree "foo", and the user
sets their email to "foo at" in foo/.bzr/control.conf to
control commits to this working tree.  But they also have a
lightweight checkout "bar" of tree "foo", and when they commit to
that, they want their commits to use their default setting
"baz at".

Your fix is to have them set their email to "foo at" in
foo/.bzr/checkout/tree.conf" instead, so that the configuration
applies only to the working tree, and not to the branch.  I believed
that your plan was that setting "foo at" in a tree.conf would
have no effect, since that is a branch configuration value, not a tree
configuration value.

I'm going to proceed under the assumption that you plan to mingle
config value *types*, and that the only difference between
branch.conf, tree.conf and repository.conf would be the object with
which they are associated.

On 12-02-16 02:39 AM, Vincent Ladeuil wrote:
>>>>>> Aaron Bentley <aaron at> writes:
> <snip/>
>> child_submit_to was also supposed to provide a default.  The 
>> repository no-working-trees file has a similar configuration
>> effect.
> That's not what I was referring to: 'default_stack_on' provides a
> default value for 'stacked_on_location'.

And child_submit_to was meant to provide a default value for
submit_to.  At least, that's what I remember.

> That's the only case I know where one option is used *only* to
> provide a default value for another option instead of relying on
> the declarations provided by the user as he sees fit in a config
> stack.

That's one way of looking at it, the way I see it, default_stack_on as
provides a default --stack-on value, just as the other location
settings like parent, submit_branch, and push_location provide
defaults to commands.  In this sense, it is also akin to log_format,
send_strict, push_strict, etc by providing command defaults.

In this sense, stacked_on_location and bound_location are the
oddballs, because they change behaviour instead of providing command

I don't think that someone who changes the default stacking setting is
intending to change the settings of all existing stacked branches
under that bzrdir.  I don't think such cascading would be a good idea.
 This implies to me that the values should have different names:
default_stack_on to provide a default to --stack-on, and
stacked_on_location to control how a stacked_branch works.

> <snip/>
>> Launchpad does not create the file after the branch's bzdir is 
>> created, it (effectively) creates the file after the *project*
>> (or package) is created.
> Whatever, neither 'project' nor 'package' exists as a concept in
> bzr (yet) as a configurable entity. It's a launchpad specific
> concept so far.

The precise time the bzrdir is created is Launchpad-specific.  My main
point was that the bzrdir providing the default_stack_on is available
before (in many cases, *long* before) the branch is created.  This is
something that any site can do.

>> I don't think that it's especially valuable to Launchpad.  I
>> think it just simplifies Bazaar configuration by having a single
>> per-location config, whether configuring a branch, tree or
>> repository.
> That's true for a standalone branch only. If I use a lightweight 
> checkout for a branch in a shared repository I still end up with
> three 'control.conf' files. And an order has to be specified
> between these files.

That doesn't contradict what I was saying.  It's still one
control.conf per location.

> And if we were to use only 'control.conf' if will introduce issues
> when 'reconfigure' is involved, how a user will resolve the
> conflicts when the files need to be merged when going from a
> lightweight checkout to a branch in a shared repo to a standalone
> branch  ?

I think the most obvious way is for settings in the tree's
control.conf to supersede settings in the branch's control.conf, which
in turn supersedes settings in the repository's control.conf.

> So I don't buy the idea that using 'control.conf' means there will
> be a single config file.

Single per location, not completely single.

> Moreover using a single 'control.conf' won't help to fix
>, quite the opposite even.

In this example, the user is trying to configure a lightweight
checkout.  By setting the email address in the lightweight checkout's
control.conf, they would override the branch's control.conf, so they
would get the effect they want.

How doesn't this address bug 185298?

It's true that it doesn't permit separate configurations for objects
at two locations.  For example, a standalone tree whose branch is
configured with "branch at", but whose tree is configured
with "tree at".  But that isn't the example in 185298, and
the original reporter, bialix, actually suggests that distinguishing
between branches and trees is confusing for new users:

> ...I've realized that both --branch and --tree are not very
> helpful names and they required from user to understand is he/she
> has branch+tree locally or lightweight checkout only. Therefore we
> may have endless source for confusion and questions from new users.
> Maybe something like --local would be better...

I think that the desire for distinct config values for branches, trees
and repositories that share a location is very rare.  For one thing, I
think standalone trees are very rare these days.  And if colocation
takes off the way I expect, they will get rarer still.

But if we do want to support this rare case, it would be possible to
augment the syntax of control.conf so that a value affected only a
tree, branch or repository.  That syntax could also be used in

If we have three files, I do picture users asking "which file should I
configure my email in", being told "whichever you like", and replying
"no, where am I supposed to do it?".  Too many options can be a bad thing.

> The same issue occurs for

Could you expand on that?  From what I see, *any* location-specific
config would work there.

> In both cases what is needed is a way to set config options for a
> given tree and explicitly not use 'branch.conf'.

I see what you mean about the first case, but not the second.

> Using a file with a name that reflect the object it configures is 
> simpler to remember for the user.

But if the user believes the object is a "standalone tree", or a
"standalone branch", then having three files to configure it is confusing.

> <snip/>
>> I strongly feel that having one way of configuring a location is 
>> simpler than having four ways of configuring a location.
> There should be a single way to configure a given object.
> That doesn't mean that sharing config options between several
> objects should be restricted.

Okay, so we'd have control.conf for shared options, and tree.conf,
branch.conf, repository.conf for unshared options?

> I prefer to let the user decide where things should be configured
> in a way that is the easiest for him.

Me too.  We just disagree about what structures will support that best.

> Note that a *lot* of users have been confused by 'locations.conf' 
> overriding options.

I know that.  My main hesitation in fixing it was
backwards-compatibility concerns.

>> I disagree that having multiple dedicated per-object files is
>> simpler than having a single file.  Why don't you have
>> defaults-tree.conf, defaults-branch.conf,
>> defaults-repository.conf? I think it is because one file is
>> simpler than three.
> No, it's because it makes no sense to have three files for a
> single object.

What is the single object?

> And AFAIK people care far more about defaults than about override
> so I don't even plan to spend time on overrides.

I feel that the user should always be in control, so overrides are
important to me.

>> Not having to remember a heirarchy of file types is one of the 
>> simplifications.
> It's a bit like saying that you cannot use a different font in a 
> chapter, a section, a paragraph or a word because it's simpler to 
> remember to not inherit settings and just set the font on every 
> word.

I don't understand what that means.

> Looking at how other software handle configurations also reveals
> that the tendency is to go from /etc/<mysoftware.conf> to
> /etc/<mysoftware>.d with a bunch of files below that. There is even
> a 'dotd' software to help address that.

I don't think that config directories are remotely analogous to
anything we do or have planned to do.

> So the effort shouldn't be on reducing the number of files

Reducing the number of file *types* was my focus.  Reducing the scope
for confusion.

> but to make it easy for the user to define his owns and more
> importantly to get feedback on how bzr/bzrlib will handle them (bzr
> config --all).

That's a good goal.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list