[RFC] I want to disable submit_branch on my computer for all branches. How can I do that?

[Stephen J. Turnbull]

vila writes:
 > >>>>> Stephen J Turnbull <stephen at xemacs.org> writes:
 > 
 >     > vila writes:
 >     >> The point here is that --remember as it is implemented is not
 >     >> related to the fact that the setting is remembered if it doesn't
 >     >> exist.
 > 
 >     > Then the complaint is about the officious behavior of "bzr merge" when
 >     > submit_branch is unset.  My advice it to just make it stop doing that,
 >     > and ask the user to always use --remember.
 > 
 > Right, that's what I've been saying since my first mail, is my English
 > *that* bad ?

No, and no.  In the recent mails, you quite clearly, in more than
adequate English, recommend using --no-remember to reset submit_branch
to None, and make that sticky so that merge won't set it in the future
(unless the user explicitly specifies --remember).

I disagree with your assessment, and consider this to be poor UI.  The
magic behavior of *merge itself* (not the remember option, which is
simple and explicit!) is convenient for some users, and inconvenient
for others.  IMO, this behavior is a mistake, because there's no
elegant way to make submit_branch=None sticky[1], so they will be
inconvenienced repeatedly.  On the other hand, users who want a
non-null submit_branch only need to specify --remember once per
branch, and they will never be inconvenienced again.  So remove the
magic behavior, the UI becomes simpler and more robust at low cost to
everybody.  Where's the problem with this?[2]

You propose to make the option magic[3] as well, which is fragile.[4]
It might work in this case, but it's an awful lot of complexity for
working around a brainstorm that turns out to be more annoyance than
it's worth.  Eg, if the submit_branch option gets renamed or split, as
has been proposed in this thread, you need to remember to fix magic in
two places.  Yuck.

As JAM points out, bzr deliberately differentiates the sync commands
push and pull from the merge command.  I think it's reasonable for
their "remember" behavior to be magic, and differ somewhat from
merge's in this respect, as they clearly imply repeated sync'ing to
the same place (that's not an absolute rule, especially for "push" in
my experience, but I suspect it's really not that hard to deal with).

 >     >> If the command switch was called --override, it would make more sense
 > 
 >     > I don't think so.  Usually an "override" command takes an argument (or
 >     > is interactive), which doesn't make sense for a boolean.
 > 
 > I fail to see why --remember is different in this respect but that
 > should be my bad English again...

Because it's not an override of something that normally should not be
changed.  "Override" connotes an exceptional behavior: "manually
overriding the autopilot" in an flying or boating emergency, for
example.  --remember is simply a convenient way of setting a user
option.

Footnotes: 
[1]  Of course 'alias merge = "merge --no-remember"' works.

[2]  True, the magic behavior cannot be implemented using an alias.  I
have long differed from Aaron in that I've never subscribed to the
opinion that this is justification for implementing magic for minor
conveniences.  "But that could just be me...". ;-)

[3]  Yes, "tristate" is an alias for "magic" in this context.

[4]  Any fantasy novel will point out that opposing a spell with a
counterspell can randomly result in a fizzle or a nuclear explosion.
Better to avoid battles of magic altogether....