[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 03:11 PM, vila wrote:
>>>>>> Aaron Bentley <aaron at aaronbentley.com> writes:
> 
>     > 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.
> 
> Nobody said otherwise.

It seemed like you were.  When you said "that's part of the discussion",
I assumed "that" referred to "the --no-options exist to force bzr to
give use [sic] the default behaviour."  I suppose "that" could refer to
"we should definitely respect the user's desire", but I don't believe
you would say that.

>     > 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.
> 
> I'm not arguing about the option name.

Aren't you?  You're saying --no-remember is obviously confusing to users
because they think it means "don't remember".  Wouldn't
- --no-force-remember avoid that issue?

> There are two booleans involved here:
> - the --remember option,
> - the existence of the setting

No, there are three booleans
- - the --remember option
- - the existence of the setting
- - whether the user supplied a location

> Giving two options to the user when a single is enough is *not* a good
> UI if we can cover all the use cases with a single one.

I don't understand in what context we would give a single option to the
user.  Are you counting --remember and --no-remember as a single option
and --always-remember, --never-remember and --conditionally-remember as two?

> The actual combination doesn't allow the user to no set
> submit_branch. 

I understand that.  I've said that we should fix that repeatedly:

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

  I agree that "never-remember" is functionality we should provide

>     > The problem is that we have three reasonable settings:
>     > 1 - don't remember it
>     > 2 - remember it if it's not set, otherwise don't (current default)
>     > 3 - remember it unconditionally (current --remember)
>     > 
>     > Making --no-remember take you back to #2 would be consistent with the
>     > current option, but also probably not what people normally want.  I
>     > think the default, and (therefore) the behaviour of --no-remember
>     > ought to be #1.
> 
> I think that's a good summary of how we want to fix the issue,

I think that's too simple, because it doesn't discuss consistency with
other commands.  As it stands, merge --no-remember would become
inconsistent with push --no-remember and pull --no-remember.  If you
want make never-remember the default behaviour of push and pull, you
should say so.  If not, we'll want to have a trinary option for them, so
we could have a trinary option for merge, too.

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

iEYEARECAAYFAk3NiyIACgkQ0F+nu1YWqI2ZFwCfTAAXJLjoGFMrAcWojJeHUuvm
FN0An0HHMVJ7kuy7QW0OVImRMFz6RD1M
=3mgg
-----END PGP SIGNATURE-----