On 10/23/2018 5:13 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Oct 17 2018, Jeff King wrote:
On Wed, Oct 17, 2018 at 02:19:59PM -0400, Eric Sunshine wrote:
On Wed, Oct 17, 2018 at 12:40 PM Ben Peart <peart...@gmail.com> wrote:
Add a reset.quietDefault config setting that sets the default value of the
--quiet flag when running the reset command. This enables users to change
the default behavior to take advantage of the performance advantages of
avoiding the scan for unstaged changes after reset. Defaults to false.
As with the previous patch, my knee-jerk reaction is that this really
feels wrong being tied to --quiet. It's particularly unintuitive.
What I _could_ see, and what would feel more natural is if you add a
new option (say, --optimize) which is more general, incorporating
whatever optimizations become available in the future, not just this
one special-case. A side-effect of --optimize is that it implies
--quiet, and that is something which can and should be documented.
Heh, I just wrote something very similar elsewhere in the thread. I'm
still not sure if it's a dumb idea, but at least we can be dumb
together.
Same here. I'm in general if favor of having the ability to configure
porcelain command-line options, but in this case it seems like it would
be more logical to head for something like:
core.uiMessaging=[default,exhaustive,lossyButFaster,quiet]
Where default would be our current "exhaustive", and this --quiet case
would be covered by lossyButFaster, but also things like the
"--no-ahead-behind" flag for git-status.
This sounds like an easy way to choose a set of default values that we
think make sense to get bundled together. That could be a way for users
to quickly choose a set of good defaults but I still think you would
want find grained control over the individual settings.
Coming up with the set of values to bundle together, figuring out the
hierarchy of precedence for this new global config->individual
config->individual command line, updating the code to make it all work
is outside the scope of this particular patch series.
Just on this implementation: The usual idiom for flags as config is
command.flag=xyz, not command.flagDefault=xyz, so this should be
reset.quiet.
Thanks, I agree and fixed that in later iterations.
