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

[Aaron Bentley]

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

On 11-05-13 12:13 PM, vila wrote:
>>>>>> Aaron Bentley <aaron at aaronbentley.com> writes:
> 
>     > On 11-05-13 04:00 AM, vila wrote:
>     >> But this is precisely what Alexander (and others including me) is
>     >> complaining about (and I don't understand the use case it's addressing,
>     >> if the user is explicit about his desire (--no-remember specified last),
>     >> we should respect it).
> 
>     > We should definitely respect the user's desire, but the "--no-" options
>     > exist to force bzr to give use the default behaviour.
> 
> Hmm, that's part of the discussion I think.

Well, I did implement them, and that's the reason I remember having at
the time.  So I think I can say why they exist.

> To me, -no applies to a boolean and is meant to reverse it. 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.

So, I wonder if this discussion would be significantly different if the
option had been named --force-remember rather than remember.  The
inverse would be --no-force-remember, which would not imply that
remembering was forbidden.

>     > So when a user uses one, their desire is to restore the default
>     > behaviour.  It's not "don't remember", it's "ignore the fact that
>     > I specified --remember".
> 
> Well, I think that's another part of the disagreement, the default
> behavior is to remember the setting

The default behaviour is to *sometimes* remember the setting

>, *BUT* the default value of the remember parameter is False !

The --remember parameter forces it to *always* remember the setting.  If
it wasn't false, we wouldn't get the default behaviour.

> Hence Martin's proposal to add another option to govern the default
> behavior.

Making it trinary is something I suggested, too:

  No, but we can switch to a RegistryOption and have --remember,
  --maybe-remember and --never-remember.

> If the command switch was called --override, it would make more sense
> and be easier to understand for the user. Discovering 'remember=False'
> in cmd_merge is not for the average user.

I don't understand what you mean by this.  We only list boolean switches
that are off by default, so "bzr help merge" should be all you need to
discover that remember=False by default.

>     > This applies to all out boolean options, and it's there so that
>     > users can alias commands to get non-default behaviour and still
>     > have a way to restore default behaviour.
> 
> That's still true for all options which govern a behavior that depend
> solely on the option itself. That's not the case here since this also
> depends on the existence of the option.

The selection of behaviour is boolean, it is either always-remember or
conditionally-remember.  The implementation details of
conditionally-remember aren't relevant, and could be arbitrarily
complex.  The point is that I think want to make it trinary: always,
conditionally, never.

>     > that you are asserting that the current behaviour does not respect
>     > user input.  When the user specifies it, it does something.
>     > That's respecting user input.
> 
> Well, s/input/expectations/ if you prefer, but the point was that some
> users want to be able to *not* set 'submit_branch' and it seem more
> common to not set 'submit_branch' than to use 'merge --remember
> --no-remember' (and I still miss how it's useful in this context).

I agree that "never-remember" is functionality we should provide, and
I've already said so.  I've already explained that the --no- options are
a generic facility that exists so that people can override aliases.
Overriding the behaviour of --no-remember would shake their confidence
that they understand the remaining --no- options.

I think that if we want to provide this functionality, we should use a
different prefix than --no-, because using --no- to provide
"never-remember" breaks user expectations and commandline compatibility.

> In the end, there are people that want to set it and people that don't.
> Keeping the actual behavior doesn't address the needs of the later, as
> Alexander said when starting this thread:

You're making it sound like the only option to help those users is to
change the behaviour of --no-remember, but that's not true.  We can help
those users by adding a new option to give them what they want.

We don't even need to change the options to solve most of Alexander's
concerns.  If we introduce a merge_location, then nothing will auto-set
the submit_location.  I think that actually moves Bazaar forward.

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

iEYEARECAAYFAk3Nd4UACgkQ0F+nu1YWqI1DbQCeIjeIDRKta0PZ21pdCd8oD4YM
sjIAoIVKw0KlaEMkeKUDRLTknUSe1PdH
=YAPS
-----END PGP SIGNATURE-----