[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 10:37 AM, Marco Pantaleoni wrote:
> On Fri, May 13, 2011 at 4:18 PM, Aaron Bentley <aaron at aaronbentley.com
> <mailto:aaron at aaronbentley.com>> wrote:

> 
> speaking as a user, this goes a bit against the principle of least
> surprise though.
> To the layman, "--no-remember" hints to the fact that the command won't
> remember, no matter what.

- --no-remember is an auto-generated option not listed in help.  The idea
was that if you know what a --no- option does, you could guess that
there's a --no-remember variant of --remember, and what it does.  So you
won't be surprised.

> The common user doesn't even want to
> know/remember if an option is on by default or not.

We only list the variant of the option that is not on by default, and it
is typically the plain version, not the --no- version.

>     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.  For example, I have "commit" aliased to
>     "commit --strict".  This does what I want 95% of the time, and the rest
>     of the time, I use commit --no-strict to restore the default behaviour.
> 
> 
> maybe something like "--default-strict" would be more appropriate in
> this case.

This gets bikesheddy.  I think that --default-strict sounds like it's
permanently changing the default behaviour of the command.

> Clearly, we'd need a "--default-OPT" for all the options.

Which we already have for all the options, except that it's called
- --no-OPT instead of --default-OPT.

>     > - change the default behavior to respect user input.
> 
>     I find it very frustrating 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.
> 
> 
> Literally, yes, but not from a UI ergonomics/design perspective.

Literally is important when you're making absolute statements like
"doesn't respect user input".  UI ergonomics/design is fluffy by nature,
and the most you can say is "this seems to be better for most people".

>     It doesn't do what *you* expect, but I believe that's based on a
>     misunderstanding of what it's supposed to do.
> 
> 
> exactly.

To be clear, what frustrates me is calling "doesn't do what I
want/expect" "doesn't respect user input".  I think that it is
hyperbole.  And it wastes effort.  Here I've been discussing this phrase
for a whole email, when we could have been productively discussing how
to improve matters for the user.

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

iEYEARECAAYFAk3NRqUACgkQ0F+nu1YWqI0unwCff5jio9Klhb/97CC+hn5g7ZXa
v3YAnRirQORe0LO9uvsG5PqI0VcOvEzQ
=fZIZ
-----END PGP SIGNATURE-----