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

Marco Pantaleoni marco.pantaleoni at gmail.com
Fri May 13 15:22:33 UTC 2011


On Fri, May 13, 2011 at 4:56 PM, Aaron Bentley <aaron at aaronbentley.com>wrote:

> -----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.
>

but as a user, I could ignore if "--option" is on by default or not. I could
just want to make sure that I turn it off, maybe using a shell alias to take
into account even possible future changes in the default behavior. If
"--no-" means "revert to default", I can't be positively sure that the
command does what I mean (ok, I can by reading the docs for every bazaar
release...).


>
> > 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.
>

if "typically" == "always", than I'm ok (not enthusiast, but ok) with the
"--no-" means default,
but if "typically" != "always" than I'm not convinced.


> >     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.
>

that would be something more like "--set-default-". We could also use
"--use-default-" if this is less ambiguous (but personally I'd prefer the
shorter version).


> > 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.
>

this is true, but so I think we'd need something else to forcibly disable
the option behaviour (if "--no-" remains there with the current meaning,
than I think we'd need a "--dont-", but *this* is getting bikesheddy). I
find more natural "--default-" to mean default, and "--no-" to mean no.


> >     > - 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".
>

for what concerns me, I don't want to make absolute statements of any
nature. I express my opinion and what appears to me more intuitive as a
bazaar user. I don't know what's best for most people. But I think we should
express our different opinions to converge to a solution appealing to the
majority.


>
> >     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.
>

I agree with you, it's an hyperbole, but I don't think it was put down in
that way to offend anyone or to be taken literally, maybe it was just to
give flavor to the subject :)

Marco


>
> 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-----
>



-- 
Marco Pantaleoni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110513/f002d9c4/attachment-0001.html>


More information about the bazaar mailing list