Push location hiding

[Stefan Monnier]

>>> All branches can be accessed directly all the time.
>> And when would it be a problem if this remote branch's branch.conf is
>> obeyed in preference to the user's locations.conf?
> I wasn't arguing that, especially.  You were:

The argument, as far as I'm concerned, is about whether locations.conf
should take precedence over branch.conf, as it currently does.

This thread was prompted by a practical case showing that this
precedence can sometimes be inconvenient, and to me it looks obvious
that it's indeed an unnatural precedence choice.

Of course, for any choice, you can always come up with some theoritcal
situation where it seems like a good idea, so you can probably come up
with cases where it's good for locations.conf to take precedence, but
I think those situations will necessarily be contrived.

> However, there are some values that might be useful to override on a
> read-only branch
> - public_branch
> - child_submit_to

Any relevant concrete cases?

> - bound

> Mostly, overriding these allows the user to compensate for inappropriate
> settings.

I.e. contrived situations.

> Disabling bound would allow the user to interact with a
> heavyweight checkout whose branch had gone missing.

By "interact" you mean "commit", right?  Since for all other operations
I can think of, the bound-ness doesn't make much of a difference.
And of course, if you can commit, you can probably fix the branch.conf
as well.

> More generally, the user should always be in control.  To the extent
> that remote sites can set a policy, users should be able to override
> that policy.

You can always copy the branch elsewhere, edit the branch.conf, and move
on, so the user is always in control in the end anyway.  The question
is: which precedence makes more sense in most cases, and I think it
makes a lot more sense (and it is more intuitive for any seasoned Unix
user) to give precedence to branch.conf rather than to locations.conf.


        Stefan