Push location hiding

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Monnier wrote:
>> But our policy is about all config data, not just push locations.  So it
>> includes the data that you would read when accessing a branch whose
>> branch.conf you don't control.
> 
> Indeed, and for that reason I think it's just wrong for branch.conf to
> ever not be under the user's control.

branch.conf part of the branch, so if the branch is readonly, then
branch.conf will not be under the user's control.

So I don't think this is a realistic option.

Perhaps you meant that we should ignore branch.conf if the user does not
control it.  But determining whether the user controls branch.conf would
require writing it, which is unsavoury and slow.

Aditionally, I believe that you are wrong-- I think that there are
settings that are valuable in a read-only context, and I don't see why
read-only users of the branch should have to guess those values:

- - nick: The branch nickname
- - public_location: useful for communicating with people who don't have
remote access
- - create_signatures: Even if not committing, it is useful to know
whether a branch requires signed commits
- - submit_branch: It can be useful to know where the branch is meant to
be merged, especially with options like merge --preview
- - parent_location: It can be useful to know what branch this branch was
created from
- - bound: "bzr info" should be able to distinguish between a heavyweight
checkout and a standalone tree.
- - bound_location: "bzr info" should accurately report what branch a
checkout is bound to.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIX7Z+0F+nu1YWqI0RAjbUAJ4xDShVWplnESVDoQo/m8SElgO2CQCfba1p
zbRTPEoFOhch0HW9uXhBxgY=
=Kacn
-----END PGP SIGNATURE-----