Re: [PATCH v1 2/2] reset: add new reset.quietDefault config setting
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Oct 23, 2018, 09:13 UTC
- Message-ID
- <874lddc9fs.fsf@evledraar.gmail.com>
- In-Reply-To
- <20181017182337.GD28326@sigill.intra.peff.net>
On Wed, Oct 17 2018, Jeff King wrote:
Show 20 quoted lines
> On Wed, Oct 17, 2018 at 02:19:59PM -0400, Eric Sunshine wrote: > >> On Wed, Oct 17, 2018 at 12:40 PM Ben Peart <peartben@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.
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.