> Deprecating doesn't mean "removing". It merely means that we add a note
> to the documentation stating that the option in question is deprecated,
> but we will keep supporting it for several years and releases to come.
Okay. Didn't know.
> This means that '--verbose' and '--show-diff' must coe
Quoting Pranit Bauva :
On Sat, Mar 19, 2016 at 4:55 PM, SZEDER Gábor wrote:
Yes, I think in general, "-v" and "-q" should work as opposites. But
that is not the case with commit, where "-v" and "-q" operate on totally
separate messages. I think that is a UX mistake, and we would not do
it tha
On Wed, Mar 16, 2016 at 02:53:17PM -0700, Stefan Beller wrote:
> On Wed, Mar 16, 2016 at 2:44 PM, Jeff King wrote:
> > On Wed, Mar 16, 2016 at 05:37:03PM -0400, Eric Sunshine wrote:
> >
> >> A much easier solution would be to update OPT_VERBOSE() to understand
> >> that negative values are "unspe
On Wed, Mar 16, 2016 at 2:44 PM, Jeff King wrote:
> On Wed, Mar 16, 2016 at 05:37:03PM -0400, Eric Sunshine wrote:
>
>> A much easier solution would be to update OPT_VERBOSE() to understand
>> that negative values are "unspecified", and then --verbose would
>> (pseudocode):
>>
>> if (value < 0
On Thu, Mar 17, 2016 at 01:32:41AM -0400, Eric Sunshine wrote:
> On Wed, Mar 16, 2016 at 9:43 PM, Jeff King wrote:
> > Arguably cmd_commit() should be using OPT_BOOL instead of OPT__VERBOSE,
> > as there is no such thing as "verbose > 1" here. But I don't think there
> > is any real user-facing c
On Thu, Mar 17, 2016 at 2:53 AM, Jeff King wrote:
> I don't think that would produce the wrong behavior, but it seems like a
> very complicated solution to a problem that can easily be solved by just
> following the usual conventions (that verbose starts at 0, options make
> it go up or down, and
On Wed, Mar 16, 2016 at 4:16 PM, Jeff King wrote:
> On Wed, Mar 16, 2016 at 02:53:17PM -0700, Stefan Beller wrote:
>
>> On Wed, Mar 16, 2016 at 2:44 PM, Jeff King wrote:
>> > On Wed, Mar 16, 2016 at 05:37:03PM -0400, Eric Sunshine wrote:
>> >
>> >> A much easier solution would be to update OPT_VE
On Wed, Mar 16, 2016 at 5:23 PM, Jeff King wrote:
> On Thu, Mar 17, 2016 at 02:36:51AM +0530, Pranit Bauva wrote:
>> I agree to you on the point that parse-options should not care about
>> the value passed to it. But I think plainly incrementing the value of
>> the variable is not a very nice way.
On Thu, Mar 17, 2016 at 3:07 AM, Eric Sunshine wrote:
> The goal comes from his GSoC microproject. Specifically, Pranit wants
> an "unspecified" value. The reason is that he is adding a
> commit.verbose= config variable to back the existing git-commit
> --verbose option. Any use of --verbose (one
On Sat, Mar 19, 2016 at 4:55 PM, SZEDER Gábor wrote:
>> Yes, I think in general, "-v" and "-q" should work as opposites. But
>> that is not the case with commit, where "-v" and "-q" operate on totally
>> separate messages. I think that is a UX mistake, and we would not do
>> it that way if designi
On Wed, Mar 16, 2016 at 05:37:03PM -0400, Eric Sunshine wrote:
> A much easier solution would be to update OPT_VERBOSE() to understand
> that negative values are "unspecified", and then --verbose would
> (pseudocode):
>
> if (value < 0)
> value = 0
> value++;
>
> and --no-verbose
> Yes, I think in general, "-v" and "-q" should work as opposites. But
> that is not the case with commit, where "-v" and "-q" operate on totally
> separate messages. I think that is a UX mistake, and we would not do
> it that way if designing from scratch. But we're stuck with it for
> historical
On Wed, Mar 16, 2016 at 9:43 PM, Jeff King wrote:
> Arguably cmd_commit() should be using OPT_BOOL instead of OPT__VERBOSE,
> as there is no such thing as "verbose > 1" here. But I don't think there
> is any real user-facing consequence of that (however, given Eric's
> suggestion, I suspect it wou
On Thu, Mar 17, 2016 at 02:36:51AM +0530, Pranit Bauva wrote:
> > So I think the caller choosing "-1" here as the "not set" value is the
> > bug.
> >
> > -Peff
>
> I agree to you on the point that parse-options should not care about
> the value passed to it. But I think plainly incrementing the v
Hey!
I noticed that parse-options does not recognize the variable which is
set to -1 so as to denote the "unspecified" value.
I did the following changes in builtin/commit.c (in master branch not
the patch I am working on) :
- static int verbose = -1
- introduced a printf statement after parsin
On Thu, Mar 17, 2016 at 2:19 AM, Jeff King wrote:
> On Thu, Mar 17, 2016 at 01:21:49AM +0530, Pranit Bauva wrote:
>
>> I noticed that parse-options does not recognize the variable which is
>> set to -1 so as to denote the "unspecified" value.
>
> Right. Like all of the stock parse-options handlers
On Thu, Mar 17, 2016 at 01:21:49AM +0530, Pranit Bauva wrote:
> I noticed that parse-options does not recognize the variable which is
> set to -1 so as to denote the "unspecified" value.
Right. Like all of the stock parse-options handlers, it does not ever
read or understand the value passed to i
On Wed, Mar 16, 2016 at 04:33:03PM -0700, Stefan Beller wrote:
> The way I understand verbosity is this:
> * You can instruct a command to be more verbose if it is supported by
> adding more -v
> * --no-verbose tells the command to be not verbose, i.e. no additional output.
>
> So my question was
18 matches
Mail list logo
