[PATCH v7] commit: add a commit.verbose config variable

[PATCH v7] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous versions of this patch are:
 - [v6] $gmane/288811
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

The changes with respect to the last version are :
 - Add '-c commit.verbose true'

It is a mistake on my part. I was a bit sleepy.
---
 Documentation/config.txt     |  4 ++++
 Documentation/git-commit.txt |  3 ++-
 builtin/commit.c             |  4 ++++
 t/t7507-commit-verbose.sh    | 29 +++++++++++++++++++++++++++++
 4 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 01cca0a..9b93f6c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean to specify whether to always include the verbose option
+	with `git commit`. See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..e0b96231 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1505,6 +1505,10 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		verbose = git_config_bool(k, v);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..5320f1e 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -96,4 +96,33 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'commit.verbose true and --verbose omitted' '
+	git -c commit.verbose=true commit --amend
+'
+
+test_expect_success 'commit.verbose true and --no-verbose' '
+	test_must_fail git -c commit.verbose=true commit --amend --no-verbose
+'
+
+test_expect_success 'commit.verbose false and --verbose' '
+	git -c commit.verbose=false commit --amend --verbose
+'
+
+test_expect_success 'commit.verbose false and --verbose omitted' '
+	test_must_fail git -c commit.verbose=false commit --amend
+'
+
+test_expect_success 'commit.verbose true and --verbose' '
+	git -c commit.verbose=true commit --amend --verbose
+'
+
+test_expect_success 'commit.verbose false and --no-verbose' '
+	test_must_fail git -c commit.verbose=false commit --amend --no-verbose
+'
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/205

Re: [PATCH v7] commit: add a commit.verbose config variable

[SZEDER Gábor]

> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.
> 
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> 
> ---
> The previous versions of this patch are:
>  - [v6] $gmane/288811
>  - [v5] $gmane/288728
>  - [v4] $gmane/288652
>  - [v3] $gmane/288634
>  - [v2] $gmane/288569
>  - [v1] $gmane/287540
> 
> The changes with respect to the last version are :
>  - Add '-c commit.verbose true'
> 
> It is a mistake on my part. I was a bit sleepy.
> ---
>  Documentation/config.txt     |  4 ++++
>  Documentation/git-commit.txt |  3 ++-
>  builtin/commit.c             |  4 ++++
>  t/t7507-commit-verbose.sh    | 29 +++++++++++++++++++++++++++++
>  4 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 01cca0a..9b93f6c 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1110,6 +1110,10 @@ commit.template::
>  	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
>  	specified user's home directory.
>  
> +commit.verbose::
> +	A boolean to specify whether to always include the verbose option
> +	with `git commit`. See linkgit:git-commit[1].
> +

You made 'commit.verbose' a boolean, so either verbose or not, ...

>  credential.helper::
>  	Specify an external helper to be called when a username or
>  	password credential is needed; the helper may consult external
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 9ec6b3c..d474226 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
>  	what changes the commit has.
>  	Note that this diff output doesn't have its
>  	lines prefixed with '#'. This diff will not be a part
> -	of the commit message.
> +	of the commit message. See the `commit.verbose` configuration
> +	variable in linkgit:git-config[1].
>  +
>  If specified twice, show in addition the unified diff between
>  what would be committed and the worktree files, i.e. the unstaged

... but note these context lines telling us that --verbose can be
specified not just once but twice (and who knows what the future may
bring).  This raises some not entirely rhetorical questions:

  - What does 'git config commit.verbose true && git commit --verbose'
    do?

  - Should 'commit.verbose' only care about the convenience of those
    who always prever '--verbose', or about those who like '-v -v',
    too?

  - If the latter, i.e. 'commit.verbose' should cater for '-v -v' as
    well, then what should 'git config commit.verbose "<verbose level
    two>" && git commit --verbose' do?

> diff --git a/builtin/commit.c b/builtin/commit.c
> index b3bd2d4..e0b96231 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1505,6 +1505,10 @@ static int git_commit_config(const char *k, const char *v, void *cb)
>  		sign_commit = git_config_bool(k, v) ? "" : NULL;
>  		return 0;
>  	}
> +	if (!strcmp(k, "commit.verbose")) {
> +		verbose = git_config_bool(k, v);
> +		return 0;
> +	}
>  
>  	status = git_gpg_config(k, v, NULL);
>  	if (status)
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> index 2ddf28c..5320f1e 100755
> --- a/t/t7507-commit-verbose.sh
> +++ b/t/t7507-commit-verbose.sh
> @@ -96,4 +96,33 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
>  	test_i18ngrep "Aborting commit due to empty commit message." err
>  '
>  
> +test_expect_success 'commit.verbose true and --verbose omitted' '
> +	git -c commit.verbose=true commit --amend
> +'
> +
> +test_expect_success 'commit.verbose true and --no-verbose' '
> +	test_must_fail git -c commit.verbose=true commit --amend --no-verbose
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose' '
> +	git -c commit.verbose=false commit --amend --verbose
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose omitted' '
> +	test_must_fail git -c commit.verbose=false commit --amend
> +'
> +
> +test_expect_success 'commit.verbose true and --verbose' '
> +	git -c commit.verbose=true commit --amend --verbose
> +'
> +
> +test_expect_success 'commit.verbose false and --no-verbose' '
> +	test_must_fail git -c commit.verbose=false commit --amend --no-verbose
> +'
> +
> +test_expect_success 'status ignores commit.verbose=true' '
> +	git -c commit.verbose=true status >actual &&
> +	! grep "^diff --git" actual
> +'
> +
>  test_done
> 
> --
> https://github.com/git/git/pull/205

Re: [PATCH v7] commit: add a commit.verbose config variable

[Pranit Bauva]

On Tue, Mar 15, 2016 at 5:01 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:

> You made 'commit.verbose' a boolean, so either verbose or not, ...
> ... but note these context lines telling us that --verbose can be
> specified not just once but twice (and who knows what the future may
> bring).  This raises some not entirely rhetorical questions:
>
>   - What does 'git config commit.verbose true && git commit --verbose'
>     do?

This is a nice thought which didn't strike me!

As Eric Sunshine mentioned ($gmane.org/288811), it would react
according to the multiple verbosity level and since its not currently
defined in `commit` it will react as it is reacting when verbosity
level is 1.

If let's say we incorporate this behavior now, it can lead to
confusion for the user (not developer) as to whether `commit` supports
multiple verbosity.

>   - Should 'commit.verbose' only care about the convenience of those
>     who always prever '--verbose', or about those who like '-v -v',
>     too?
>
>   - If the latter, i.e. 'commit.verbose' should cater for '-v -v' as
>     well, then what should 'git config commit.verbose "<verbose level
>     two>" && git commit --verbose' do?

If I was the user, I would use multiple levels of verbosity only where
I would feel that there is some problem happening with the commit that
is in progress. Having an "awkward" commit isn't usual and definitely
not every time. Though if in future it is required, We can add edit
the line namely :

 if(!strcmp(k, "commit.verbose")) {
-     verbose = git_config_bool(k, v);
+    verbose = git_config_int(k, v);
 return 0;
 }

Additionally we will have to define scenarios and mention them in the
documentation as to how `commit` will react as this cannot be known by
intuition. This would complicate things for the user who is reading
the man pages.

Regards,
Pranit Bauva

Re: [PATCH v7] commit: add a commit.verbose config variable

[Eric Sunshine]

On Tue, Mar 15, 2016 at 3:00 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Tue, Mar 15, 2016 at 5:01 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> You made 'commit.verbose' a boolean, so either verbose or not, ...
>> ... but note these context lines telling us that --verbose can be
>> specified not just once but twice (and who knows what the future may
>> bring).  This raises some not entirely rhetorical questions:
>>
>>   - What does 'git config commit.verbose true && git commit --verbose'
>>     do?
>
> This is a nice thought which didn't strike me!
>
> As Eric Sunshine mentioned ($gmane.org/288811), it would react
> according to the multiple verbosity level and since its not currently
> defined in `commit` it will react as it is reacting when verbosity
> level is 1.

I get the feeling that you missed SZEDER's point which was that
git-commit already behaves differently when --verbose is specified
multiple times. (I hadn't gotten around to reviewing that part of the
code yet, so I'm glad that SZEDER saved me the effort.)

The new config variable, which is boolean, doesn't mesh well with
multiple verbosity levels. For instance, with a combination of
commit.verbose=true and a single --verbose, the code will think that
--verbose was given twice and use verbosity level 2, which is not at
all intuitive and would be surprising for the user. So, SZEDER was
asking how this impedance mismatch can be rectified.

A possibly sane approach would be to make commit.verbose be a
verbosity level rather than boolean, and behave as follows:

1. if --verbose is used (one or more), completely ignore commit.verbose.
2. else, if commit.verbose is set, use it.
3. else, default behavior.

I'm not sure if this makes sense, but as a convenience, maybe also
recognize "true" and "false" as aliases for 1 and 0, respectively, for
values of commit.verbose.

And, of course you'd want to test these behaviors.

Re: [PATCH v7] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Mar 16, 2016 at 12:54 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> As Eric Sunshine mentioned ($gmane.org/288811), it would react
>> according to the multiple verbosity level and since its not currently
>> defined in `commit` it will react as it is reacting when verbosity
>> level is 1.
>
> I get the feeling that you missed SZEDER's point which was that
> git-commit already behaves differently when --verbose is specified
> multiple times. (I hadn't gotten around to reviewing that part of the
> code yet, so I'm glad that SZEDER saved me the effort.)

My bad! I missed SZEDER's point.

> The new config variable, which is boolean, doesn't mesh well with
> multiple verbosity levels. For instance, with a combination of
> commit.verbose=true and a single --verbose, the code will think that
> --verbose was given twice and use verbosity level 2, which is not at
> all intuitive and would be surprising for the user. So, SZEDER was
> asking how this impedance mismatch can be rectified.
>
> A possibly sane approach would be to make commit.verbose be a
> verbosity level rather than boolean, and behave as follows:
>
> 1. if --verbose is used (one or more), completely ignore commit.verbose.
> 2. else, if commit.verbose is set, use it.
> 3. else, default behavior.
>
> I'm not sure if this makes sense, but as a convenience, maybe also
> recognize "true" and "false" as aliases for 1 and 0, respectively, for
> values of commit.verbose.
>
> And, of course you'd want to test these behaviors.

This seems a good approach to me. I have two ideas of implementing it.
First one to introduce a new variable `config_verbose` to store the
value read by the config. Till then the value of verbose can be set
through command line options. Depending on the situation as you
described, it can then make the modification. Another approach would
be to swap the places where the configuration file is read and where
arguments are parsed. I personally think the first approach as more
appropriate as in the latter one, there might be some parts of code
which can break. As for the part of alias, I can use the method
git_config_bool_or_int() which takes care about aliasing for me. I
will also write tests for this behavior.

Re: [PATCH v7] commit: add a commit.verbose config variable

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> First one to introduce a new variable `config_verbose` to store the
> value read by the config. Till then the value of verbose can be set
> through command line options. Depending on the situation as you
> described, it can then make the modification. Another approach would
> be to swap the places where the configuration file is read and where
> arguments are parsed. I personally think the first approach as more
> appropriate as in the latter one, there might be some parts of code
> which can break.

Changing config-first-and-then-command-line is likely to break
things, unless you do a lot more work to avoid breakage ;-)

Wouldn't it be the simplest to do:

 * initialize opt-verbose to "unspecified";
 * initialize config-verbosity to "unspecified";
 * let git_config() update config-verbosity;
 * let parse_options() update opt-verbose.

and then

 * if opt-verbose is still "unspecified", then overwrite it with
   config-verbosity.

 * if opt-verbose is still "unspecified" after that, then neither
   the command line nor the configuration gave you verbosity.

 * otherwise opt-verbose at this point has what verbosity level to
   use.

?

Re: [PATCH v7] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Mar 16, 2016 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> First one to introduce a new variable `config_verbose` to store the
>> value read by the config. Till then the value of verbose can be set
>> through command line options. Depending on the situation as you
>> described, it can then make the modification. Another approach would
>> be to swap the places where the configuration file is read and where
>> arguments are parsed. I personally think the first approach as more
>> appropriate as in the latter one, there might be some parts of code
>> which can break.
>
> Changing config-first-and-then-command-line is likely to break
> things, unless you do a lot more work to avoid breakage ;-)

I had guessed this correctly! :)

> Wouldn't it be the simplest to do:
>
>  * initialize opt-verbose to "unspecified";
>  * initialize config-verbosity to "unspecified";
>  * let git_config() update config-verbosity;
>  * let parse_options() update opt-verbose.
>
> and then
>
>  * if opt-verbose is still "unspecified", then overwrite it with
>    config-verbosity.
>
>  * if opt-verbose is still "unspecified" after that, then neither
>    the command line nor the configuration gave you verbosity.
>
>  * otherwise opt-verbose at this point has what verbosity level to
>    use.
>
> ?
I just realized that both of our approaches breaks the condition with
no-verbose.
If commit.verbose is set to true and --no-verbose is passed, then it
should not give verbose output.
But I suppose that is the reason you are saying "unspecified". If
`opt-verbose` is 0 then it would mean --no-verbose is activated. If it
is still "unspecified" then there would not be any such option. But
now the question is how do you set a variable as "unspecified". I can
set `opt-verbose` as -1. But then I am still not convinced for the
requirement of another variable `opt-verbose` as I believe that the
`verbose` and `config_verbose` are quite enough for this. First
`config_verbose` will read from configuration file. Then `verbose`
will read from command line options. If `verbose` is unspecified then
it will use `config_verbose`, else if `verbose` is 0 it will ignore
`config_verbose` else if `verbose` has a value greater than 0 then it
will stay as it is. Or is there something else which I forgot to
consider?

Re: [PATCH v7] commit: add a commit.verbose config variable

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> ... But then I am still not convinced for the
> requirement of another variable `opt-verbose` as I believe that the
> `verbose` and `config_verbose` are quite enough for this.
> ... Or is there something else which I forgot to
> consider?

I do not think we need three variables.  If there is one "verbose"
that is initialized to "unspecified" (which must be different from
"no", "yes", "even more verbose"), then it is perfectly fine to
reuse that as if it were "opt-verbose" in my outline.  I just used
that name to make it clear where the value comes from for these two
entities, i.e. to contrast "opt vs config" (as opposed to "(nothing)
vs config").

Re: [PATCH v7] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Mar 16, 2016 at 2:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> ... But then I am still not convinced for the
>> requirement of another variable `opt-verbose` as I believe that the
>> `verbose` and `config_verbose` are quite enough for this.
>> ... Or is there something else which I forgot to
>> consider?
>
> I do not think we need three variables.  If there is one "verbose"
> that is initialized to "unspecified" (which must be different from
> "no", "yes", "even more verbose"), then it is perfectly fine to
> reuse that as if it were "opt-verbose" in my outline.  I just used
> that name to make it clear where the value comes from for these two
> entities, i.e. to contrast "opt vs config" (as opposed to "(nothing)
> vs config").

I just wanted to clear out the confusion! I will send the updated
patch with tests soon!

[PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values

[Pranit Bauva]

The reason to make it consider negative values or more specifically
"unspecified" values is to give the ability to differentiate between
once, multiple time or with --no-option.

Eg. :
initialize verbose = -1
`git commit` => verbose = -1
`git commit -v` => verbose = 1
`git commit -v -v` => verbose = 2
`git commit --no-verbose` => verbose = 0

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes introduced:
Use a different language in commit message to make the change and its
utility more clear.
---
 Documentation/technical/api-parse-options.txt | 6 ++++--
 parse-options.c                               | 8 +++++++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..a908d8a 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,10 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	If the `int_var` is negative and `--option` is absent,
+	then it will retain its value. Otherwise it will first set
+	`int_var` to 0 and then increment it on each use of `--option`,
+	and reset to zero with `--no-option`.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..86d30bd 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
-		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
+		if (unset)
+			*(int *)opt->value = 0;
+		else {
+			if (*(int *)opt->value < 0)
+				*(int *)opt->value = 0;
+			*(int *)opt->value += 1;
+		}
 		return 0;
 
 	case OPTION_SET_INT:

--
https://github.com/git/git/pull/213

[PATCH v8 2/2] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:

 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

Changes with respect to the previous patch:
 - Consider multiple verbosity as mentioned by SZEDER.
 - To implement this, change the way in which OPTION_COUNTUP() works.

Approach used: (Suggested by Junio Hamano and Eric Sunshine)
 - initialize verbose to "unspecified"
 - initialize config_verbose to "unspecified"
 - let git_config() update config_verbose
 - let parse_options() update verbose

 Then:
 - If verbose is still "unspecified", then overwrite it with
   config_verbose.
 - If verbose is still "unspecified" after that, then neither the
   command line nor the configuration gave you verbosity.
 - Otherwise verbose at this point has the verbosity level to use so set
   it to 0.
---
 Documentation/config.txt     |  4 ++++
 Documentation/git-commit.txt |  3 ++-
 builtin/commit.c             | 17 +++++++++++++-
 t/t7507-commit-verbose.sh    | 55 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 77 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..ad85be0 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1505,6 +1507,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1661,14 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+
+	if (verbose < 0) {
+		if (config_verbose > -1)
+			verbose = config_verbose;
+		else
+			verbose = 0;
+	}
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..dda674e 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -96,4 +96,59 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'commit.verbose true and --verbose omitted' '
+	git -c commit.verbose=true commit --amend
+'
+
+test_expect_success 'commit.verbose true and --verbose' '
+	(
+		GIT_EDITOR=cat &&
+		export GIT_EDITOR &&
+		git -c commit.verbose=true commit --amend --verbose
+	) &&
+	grep "^diff --git" .git/COMMIT_EDITMSG >out &&
+	wc -l out | grep "1"
+'
+
+test_expect_success 'commit.verbose true and -v -v' '
+	(
+		GIT_EDITOR=cat &&
+		export GIT_EDITOR &&
+		git -c commit.verbose=true commit --amend -v -v
+	) &&
+	grep "# Changes not staged for commit" .git/COMMIT_EDITMSG >out &&
+	wc -l out | grep "2"
+'
+
+test_expect_success 'commit.verbose true and --no-verbose' '
+	test_must_fail git -c commit.verbose=true commit --amend --no-verbose
+'
+
+test_expect_success 'commit.verbose false and --verbose' '
+	git -c commit.verbose=false commit --amend --verbose
+'
+
+test_expect_success 'commit.verbose false and -v -v' '
+	(
+		GIT_EDITOR=cat &&
+		export GIT_EDITOR &&
+		git -c commit.verbose=false commit --amend -v -v
+	) &&
+	grep "# Changes not staged for commit" .git/COMMIT_EDITMSG >out &&
+	wc -l out | grep "2"
+'
+
+test_expect_success 'commit.verbose false and --verbose omitted' '
+	test_must_fail git -c commit.verbose=false commit --amend
+'
+
+test_expect_success 'commit.verbose false and --no-verbose' '
+	test_must_fail git -c commit.verbose=false commit --amend --no-verbose
+'
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/213

Re: [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> The reason to make it consider negative values or more specifically
> "unspecified" values is to give the ability to differentiate between
> once, multiple time or with --no-option.
>
> Eg. :
> initialize verbose = -1
> `git commit` => verbose = -1
> `git commit -v` => verbose = 1
> `git commit -v -v` => verbose = 2
> `git commit --no-verbose` => verbose = 0

A few more things I noticed about this are:

 - Many uses of COUNTUP has now been replaced with BOOL and what
   remains are verbose/quiet/force.

 - This change will not affect existing users of COUNTUP at all, as
   long as they use the initial value of 0 (or more), as there is no
   mechanism to decrement.  The only thing the command line can do
   is to reset it to zero with "--no-foo".

So it seems a safe and sensible change.  Even though I suspect that
the justification can be written more clearly, I am not sure if it
worth the extra effort.

>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>
> ---
> The discussion about this patch:
> [1] : http://thread.gmane.org/gmane.comp.version-control.git/289027
>
> Previous version of the patch:
> [v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061
>
> Changes introduced:
> Use a different language in commit message to make the change and its
> utility more clear.
> ---
>  Documentation/technical/api-parse-options.txt | 6 ++++--
>  parse-options.c                               | 8 +++++++-
>  2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
> index 5f0757d..a908d8a 100644
> --- a/Documentation/technical/api-parse-options.txt
> +++ b/Documentation/technical/api-parse-options.txt
> @@ -144,8 +144,10 @@ There are some macros to easily define options:
>  
>  `OPT_COUNTUP(short, long, &int_var, description)`::
>  	Introduce a count-up option.
> -	`int_var` is incremented on each use of `--option`, and
> -	reset to zero with `--no-option`.
> +	If the `int_var` is negative and `--option` is absent,
> +	then it will retain its value. Otherwise it will first set
> +	`int_var` to 0 and then increment it on each use of `--option`,
> +	and reset to zero with `--no-option`.
>  
>  `OPT_BIT(short, long, &int_var, description, mask)`::
>  	Introduce a boolean option.
> diff --git a/parse-options.c b/parse-options.c
> index 47a9192..86d30bd 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
>  		return 0;
>  
>  	case OPTION_COUNTUP:
> -		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
> +		if (unset)
> +			*(int *)opt->value = 0;
> +		else {
> +			if (*(int *)opt->value < 0)
> +				*(int *)opt->value = 0;
> +			*(int *)opt->value += 1;
> +		}
>  		return 0;
>  
>  	case OPTION_SET_INT:
>
> --
> https://github.com/git/git/pull/213

Re: [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values

[Pranit Bauva]

On Sat, Mar 19, 2016 at 4:29 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> The reason to make it consider negative values or more specifically
>> "unspecified" values is to give the ability to differentiate between
>> once, multiple time or with --no-option.
>>
>> Eg. :
>> initialize verbose = -1
>> `git commit` => verbose = -1
>> `git commit -v` => verbose = 1
>> `git commit -v -v` => verbose = 2
>> `git commit --no-verbose` => verbose = 0
>
> A few more things I noticed about this are:
>
>  - Many uses of COUNTUP has now been replaced with BOOL and what
>    remains are verbose/quiet/force.
>
>  - This change will not affect existing users of COUNTUP at all, as
>    long as they use the initial value of 0 (or more), as there is no
>    mechanism to decrement.  The only thing the command line can do
>    is to reset it to zero with "--no-foo".
>
> So it seems a safe and sensible change.  Even though I suspect that
> the justification can be written more clearly, I am not sure if it
> worth the extra effort.

I can include this paragraph. Some people might have a bit difficulty
in knowing the importance as they might not have followed my earlier
patches. To bridge this gap, I can include your paragraph in the
commit message. Any other particular things you want me to justify? I
will be glad to send another re-roll of this.

Regards,
Pranit Bauva

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Eric Sunshine]

On Fri, Mar 18, 2016 at 5:19 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.
>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/builtin/commit.c b/builtin/commit.c
> @@ -1654,6 +1661,14 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> +       if (verbose < 0) {
> +               if (config_verbose > -1)
> +                       verbose = config_verbose;
> +               else
> +                       verbose = 0;
> +       }

I think it's more common in this codebase to compare against -1
directly rather than <0, so:

    if (verbose == -1) {
        if (config_verbose != -1)
            verbose = config_verbose;
        else
            verbose = 0;
    }

Or, this might be easier to read:

    if (verbose == -1)
        verbose = config_verbose;

    if (verbose == -1)
        verbose = 0;

But, this likely isn't better:

    if (verbose == -1)
        verbose = config_verbose == -1 ? 0 : config_verbose;

Anyhow, probably not worth a re-roll.

> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> @@ -96,4 +96,59 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
> +test_expect_success 'commit.verbose true and --verbose' '
> +       (
> +               GIT_EDITOR=cat &&
> +               export GIT_EDITOR &&
> +               git -c commit.verbose=true commit --amend --verbose

Easier would be to write this as:

    GIT_EDITOR=cat git -c commit.verbose=true commit --amend --verbose

and then you wouldn't need the subhsell.

However, more intuitive would probably be to create another "editor"
similar to the 'check-for-diff' editor this script already uses. (The
'check-for-diff' editor is an obvious example about how to go about
such an undertaking.) You would need to invoke 'test_set_editor' in a
subshell for this particular test in order to avoid clobbering the
global editor used by this script. Or, have a preparatory patch which
ditches the global setting of the editor and has each test invoke
'test_set_editor' as needed (and only if needed).

Same comments apply to the other new tests which use a custom "editor".

> +       ) &&
> +       grep "^diff --git" .git/COMMIT_EDITMSG >out &&
> +       wc -l out | grep "1"
> +'
> +
> +test_expect_success 'commit.verbose true and -v -v' '
> +       (
> +               GIT_EDITOR=cat &&
> +               export GIT_EDITOR &&
> +               git -c commit.verbose=true commit --amend -v -v
> +       ) &&
> +       grep "# Changes not staged for commit" .git/COMMIT_EDITMSG >out &&
> +       wc -l out | grep "2"
> +'
> +
> +test_expect_success 'commit.verbose true and --no-verbose' '
> +       test_must_fail git -c commit.verbose=true commit --amend --no-verbose
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose' '
> +       git -c commit.verbose=false commit --amend --verbose
> +'
> +
> +test_expect_success 'commit.verbose false and -v -v' '
> +       (
> +               GIT_EDITOR=cat &&
> +               export GIT_EDITOR &&
> +               git -c commit.verbose=false commit --amend -v -v
> +       ) &&
> +       grep "# Changes not staged for commit" .git/COMMIT_EDITMSG >out &&
> +       wc -l out | grep "2"
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose omitted' '
> +       test_must_fail git -c commit.verbose=false commit --amend
> +'
> +
> +test_expect_success 'commit.verbose false and --no-verbose' '
> +       test_must_fail git -c commit.verbose=false commit --amend --no-verbose
> +'
> +
> +test_expect_success 'status ignores commit.verbose=true' '
> +       git -c commit.verbose=true status >actual &&
> +       ! grep "^diff --git" actual
> +'
> +
>  test_done

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Pranit Bauva]

On Sun, Mar 20, 2016 at 9:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Fri, Mar 18, 2016 at 5:19 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Add commit.verbose configuration variable as a convenience for those
>> who always prefer --verbose.
>>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> @@ -1654,6 +1661,14 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>> +       if (verbose < 0) {
>> +               if (config_verbose > -1)
>> +                       verbose = config_verbose;
>> +               else
>> +                       verbose = 0;
>> +       }
>
> I think it's more common in this codebase to compare against -1
> directly rather than <0, so:
>
>     if (verbose == -1) {
>         if (config_verbose != -1)
>             verbose = config_verbose;
>         else
>             verbose = 0;
>     }
>
> Or, this might be easier to read:
>
>     if (verbose == -1)
>         verbose = config_verbose;
>
>     if (verbose == -1)
>         verbose = 0;
>
> But, this likely isn't better:
>
>     if (verbose == -1)
>         verbose = config_verbose == -1 ? 0 : config_verbose;
>
> Anyhow, probably not worth a re-roll.

I will note this for future patches.

>
>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>> @@ -96,4 +96,59 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
>> +test_expect_success 'commit.verbose true and --verbose' '
>> +       (
>> +               GIT_EDITOR=cat &&
>> +               export GIT_EDITOR &&
>> +               git -c commit.verbose=true commit --amend --verbose
>
> Easier would be to write this as:
>
>     GIT_EDITOR=cat git -c commit.verbose=true commit --amend --verbose
>
> and then you wouldn't need the subhsell.

True. I will update this.

> However, more intuitive would probably be to create another "editor"
> similar to the 'check-for-diff' editor this script already uses. (The
> 'check-for-diff' editor is an obvious example about how to go about
> such an undertaking.) You would need to invoke 'test_set_editor' in a
> subshell for this particular test in order to avoid clobbering the
> global editor used by this script. Or, have a preparatory patch which
> ditches the global setting of the editor and has each test invoke
> 'test_set_editor' as needed (and only if needed).

I guess it would complicate things as sometimes I need to check
whether it has 1 line and sometimes 2 lines.

> Same comments apply to the other new tests which use a custom "editor".
>
>> +       ) &&
>> +       grep "^diff --git" .git/COMMIT_EDITMSG >out &&
>> +       wc -l out | grep "1"
>> +'
>> +
>> +test_expect_success 'commit.verbose true and -v -v' '
>> +       (
>> +               GIT_EDITOR=cat &&
>> +               export GIT_EDITOR &&
>> +               git -c commit.verbose=true commit --amend -v -v
>> +       ) &&
>> +       grep "# Changes not staged for commit" .git/COMMIT_EDITMSG >out &&
>> +       wc -l out | grep "2"
>> +'
>> +
>> +test_expect_success 'commit.verbose true and --no-verbose' '
>> +       test_must_fail git -c commit.verbose=true commit --amend --no-verbose
>> +'
>> +
>> +test_expect_success 'commit.verbose false and --verbose' '
>> +       git -c commit.verbose=false commit --amend --verbose
>> +'
>> +
>> +test_expect_success 'commit.verbose false and -v -v' '
>> +       (
>> +               GIT_EDITOR=cat &&
>> +               export GIT_EDITOR &&
>> +               git -c commit.verbose=false commit --amend -v -v
>> +       ) &&
>> +       grep "# Changes not staged for commit" .git/COMMIT_EDITMSG >out &&
>> +       wc -l out | grep "2"
>> +'
>> +
>> +test_expect_success 'commit.verbose false and --verbose omitted' '
>> +       test_must_fail git -c commit.verbose=false commit --amend
>> +'
>> +
>> +test_expect_success 'commit.verbose false and --no-verbose' '
>> +       test_must_fail git -c commit.verbose=false commit --amend --no-verbose
>> +'
>> +
>> +test_expect_success 'status ignores commit.verbose=true' '
>> +       git -c commit.verbose=true status >actual &&
>> +       ! grep "^diff --git" actual
>> +'
>> +
>>  test_done

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Eric Sunshine]

On Sun, Mar 20, 2016 at 7:05 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Sun, Mar 20, 2016 at 9:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> However, more intuitive would probably be to create another "editor"
>> similar to the 'check-for-diff' editor this script already uses. (The
>> 'check-for-diff' editor is an obvious example about how to go about
>> such an undertaking.) You would need to invoke 'test_set_editor' in a
>> subshell for this particular test in order to avoid clobbering the
>> global editor used by this script. Or, have a preparatory patch which
>> ditches the global setting of the editor and has each test invoke
>> 'test_set_editor' as needed (and only if needed).
>
> I guess it would complicate things as sometimes I need to check
> whether it has 1 line and sometimes 2 lines.

It's not really a big complication. If I'm reading the patch
correctly, you should be able to re-use the existing check-for-diff
"editor" for the first of the new tests for which you're currently
setting a custom GIT_EDITOR. To do so, you will need to modify
check-for-diff to also count lines and assert that only one was found,
which should work for the new test and continue working for the
existing tests.

Then, you just need to create one more "editor" for the two tests
where you set custom GIT_EDITOR and expect two lines.

By the way, I forgot to mention in the review that, rather than:

    wc -l out | grep "1"

for counting lines in a test script, you'd use:

    test_line_count = 1 out

However, if you're doing it in an "editor" (which I recommend), then you'd use:

    test $(wc -l <out) = 1

And, another "by the way": You can use the write_script() function to
simplify creation of the new "editor(s)".

In fact, it would be nice to convert creation of the check-for-diff
"editor" to use write_script, as well. So, basically, I'm suggesting
splitting the current patch into three, where the first two are
preparatory cleanups:

1. use write_script() to create the check-for-diff "editor" rather
than creating it manually

2. drop the global test_set_editor() and instead have each test invoke
it as needed (and only if needed)

3. the current patch which adds new tests along with a new "editor"

Alternatively, combine #1 and #2 into a single patch which drops the
global test_set_editor() and, as an aside, also does "while here,
let's use write_script() to create 'check-for'diff' rather than doing
so manually".

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Pranit Bauva]

On Sun, Mar 20, 2016 at 11:04 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sun, Mar 20, 2016 at 7:05 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Sun, Mar 20, 2016 at 9:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> However, more intuitive would probably be to create another "editor"
>>> similar to the 'check-for-diff' editor this script already uses. (The
>>> 'check-for-diff' editor is an obvious example about how to go about
>>> such an undertaking.) You would need to invoke 'test_set_editor' in a
>>> subshell for this particular test in order to avoid clobbering the
>>> global editor used by this script. Or, have a preparatory patch which
>>> ditches the global setting of the editor and has each test invoke
>>> 'test_set_editor' as needed (and only if needed).
>>
>> I guess it would complicate things as sometimes I need to check
>> whether it has 1 line and sometimes 2 lines.
>
> It's not really a big complication. If I'm reading the patch
> correctly, you should be able to re-use the existing check-for-diff
> "editor" for the first of the new tests for which you're currently
> setting a custom GIT_EDITOR. To do so, you will need to modify
> check-for-diff to also count lines and assert that only one was found,
> which should work for the new test and continue working for the
> existing tests.
>
> Then, you just need to create one more "editor" for the two tests
> where you set custom GIT_EDITOR and expect two lines.
>
> By the way, I forgot to mention in the review that, rather than:
>
>     wc -l out | grep "1"
>
> for counting lines in a test script, you'd use:
>
>     test_line_count = 1 out
>
> However, if you're doing it in an "editor" (which I recommend), then you'd use:
>
>     test $(wc -l <out) = 1
>
> And, another "by the way": You can use the write_script() function to
> simplify creation of the new "editor(s)".

Thanks for a detailed explanation.

> In fact, it would be nice to convert creation of the check-for-diff
> "editor" to use write_script, as well. So, basically, I'm suggesting
> splitting the current patch into three, where the first two are
> preparatory cleanups:
>
> 1. use write_script() to create the check-for-diff "editor" rather
> than creating it manually
>
> 2. drop the global test_set_editor() and instead have each test invoke
> it as needed (and only if needed)
>
> 3. the current patch which adds new tests along with a new "editor"
>
> Alternatively, combine #1 and #2 into a single patch which drops the
> global test_set_editor() and, as an aside, also does "while here,
> let's use write_script() to create 'check-for'diff' rather than doing
> so manually".

These changes seem nice. I will update and send the patch.

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> On Sun, Mar 20, 2016 at 11:04 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> ...
>> Alternatively, combine #1 and #2 into a single patch which drops the
>> global test_set_editor() and, as an aside, also does "while here,
>> let's use write_script() to create 'check-for'diff' rather than doing
>> so manually".
>
> These changes seem nice. I will update and send the patch.

So, has anything happened to this topic or has it been abandoned?

I am not in a hurry, just wanted to see if I need to keep the old
one in my tree as a reminder to myself.

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Pranit Bauva]

On Thu, Mar 24, 2016 at 12:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> On Sun, Mar 20, 2016 at 11:04 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> ...
>>> Alternatively, combine #1 and #2 into a single patch which drops the
>>> global test_set_editor() and, as an aside, also does "while here,
>>> let's use write_script() to create 'check-for'diff' rather than doing
>>> so manually".
>>
>> These changes seem nice. I will update and send the patch.
>
> So, has anything happened to this topic or has it been abandoned?
>
> I am not in a hurry, just wanted to see if I need to keep the old
> one in my tree as a reminder to myself.

Sorry for that! Actually I am bit caught up with writing my proposal
for GSoC 2016. I would be able to complete that in around an hour.
Then will work on this. Then on the shell function -> C function
porting patch. Please bear with me for a little while.

Re: [PATCH v8 2/2] commit: add a commit.verbose config variable

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> On Thu, Mar 24, 2016 at 12:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Pranit Bauva <pranit.bauva@gmail.com> writes:
>>
>>> On Sun, Mar 20, 2016 at 11:04 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> ...
>>>> Alternatively, combine #1 and #2 into a single patch which drops the
>>>> global test_set_editor() and, as an aside, also does "while here,
>>>> let's use write_script() to create 'check-for'diff' rather than doing
>>>> so manually".
>>>
>>> These changes seem nice. I will update and send the patch.
>>
>> So, has anything happened to this topic or has it been abandoned?
>>
>> I am not in a hurry, just wanted to see if I need to keep the old
>> one in my tree as a reminder to myself.
>
> Sorry for that! Actually I am bit caught up with writing my proposal
> for GSoC 2016. I would be able to complete that in around an hour.
> Then will work on this. Then on the shell function -> C function
> porting patch. Please bear with me for a little while.

Oh, no worries. Naturally the application/proposal should take
higher priority.

Thanks.

[PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Pranit Bauva]

Also remove test_set_editor from global scope and use it in whichever
test it is required.
---
 t/t7507-commit-verbose.sh | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..cf95efb 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -3,12 +3,11 @@
 test_description='verbose commit template'
 . ./test-lib.sh
 
-cat >check-for-diff <<EOF
-#!$SHELL_PATH
-exec grep '^diff --git' "\$1"
+write_script "check-for-diff" <<-\EOF &&
+grep '^diff --git' "$1" >out &&
+test $(wc -l <out) = 1
 EOF
 chmod +x check-for-diff
-test_set_editor "$PWD/check-for-diff"
 
 cat >message <<'EOF'
 subject
@@ -23,6 +22,7 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'initial commit shows verbose diff' '
+	test_set_editor "$PWD/check-for-diff" &&
 	git commit --amend -v
 '
 
@@ -38,11 +38,13 @@ check_message() {
 }
 
 test_expect_success 'verbose diff is stripped out' '
+	test_set_editor "$PWD/check-for-diff" &&
 	git commit --amend -v &&
 	check_message message
 '
 
 test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
+	test_set_editor "$PWD/check-for-diff" &&
 	git config diff.mnemonicprefix true &&
 	git commit --amend -v &&
 	check_message message
@@ -66,11 +68,13 @@ test_expect_success 'diff in message is retained without -v' '
 '
 
 test_expect_success 'diff in message is retained with -v' '
+	test_set_editor "$PWD/check-for-diff" &&
 	git commit --amend -F diff -v &&
 	check_message diff
 '
 
 test_expect_success 'submodule log is stripped out too with -v' '
+	test_set_editor "$PWD/check-for-diff" &&
 	git config diff.submodule log &&
 	git submodule add ./. sub &&
 	git commit -m "sub added" &&

--
https://github.com/git/git/pull/218

[PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

[Pranit Bauva]

The reason to make it consider negative values or more specifically
"unspecified" values is to give the ability to differentiate between
once, multiple time or with --no-option.

Eg. :
initialize verbose = -1
`git commit` => verbose = -1
`git commit -v` => verbose = 1
`git commit -v -v` => verbose = 2
`git commit --no-verbose` => verbose = 0

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes introduced:
Use a different language in commit message to make the change and its
utility more clear.
---
 Documentation/technical/api-parse-options.txt | 6 ++++--
 parse-options.c                               | 8 +++++++-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..a908d8a 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,10 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	If the `int_var` is negative and `--option` is absent,
+	then it will retain its value. Otherwise it will first set
+	`int_var` to 0 and then increment it on each use of `--option`,
+	and reset to zero with `--no-option`.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..86d30bd 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
-		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
+		if (unset)
+			*(int *)opt->value = 0;
+		else {
+			if (*(int *)opt->value < 0)
+				*(int *)opt->value = 0;
+			*(int *)opt->value += 1;
+		}
 		return 0;
 
 	case OPTION_SET_INT:

--
https://github.com/git/git/pull/218

[PATCH v9 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:
 - [v8] $gmane/288820
 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

Changes with respect to the previous patch:
 - Compare with -1 as only -1 value is used for unspecified behavior.
 - Write clean tests
---
 Documentation/config.txt     |  4 ++++
 Documentation/git-commit.txt |  3 ++-
 builtin/commit.c             | 13 ++++++++++-
 t/t7507-commit-verbose.sh    | 51 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..db65c03 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1505,6 +1507,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1661,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+
+	if (verbose == -1)
+		verbose = (config_verbose == -1) ? 0 : config_verbose;
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index cf95efb..66deac3 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -9,6 +9,12 @@ test $(wc -l <out) = 1
 EOF
 chmod +x check-for-diff
 
+write_script "check-for-double-diff" <<-\EOF &&
+grep '# Changes not staged for commit' "$1" >out &&
+test $(wc -l <out) = 2
+EOF
+chmod +x check-for-double-diff
+
 cat >message <<'EOF'
 subject
 
@@ -100,4 +106,49 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'commit.verbose true and --verbose omitted' '
+	test_set_editor "$PWD/check-for-diff" &&
+	git -c commit.verbose=true commit --amend
+'
+
+test_expect_success 'commit.verbose true and --verbose' '
+	test_set_editor "$PWD/check-for-diff" &&
+	git -c commit.verbose=true commit --amend --verbose
+'
+
+test_expect_success 'commit.verbose true and -v -v' '
+	test_set_editor "$PWD/check-for-double-diff" &&
+	git -c commit.verbose=true commit --amend -v -v
+'
+
+test_expect_success 'commit.verbose true and --no-verbose' '
+	test_set_editor "$PWD/check-for-diff" &&
+	test_must_fail git -c commit.verbose=true commit --amend --no-verbose
+'
+
+test_expect_success 'commit.verbose false and --verbose' '
+	test_set_editor "$PWD/check-for-diff" &&
+	git -c commit.verbose=false commit --amend --verbose
+'
+
+test_expect_success 'commit.verbose false and -v -v' '
+	test_set_editor "$PWD/check-for-double-diff" &&
+	git -c commit.verbose=false commit --amend -v -v
+'
+
+test_expect_success 'commit.verbose false and --verbose omitted' '
+	test_set_editor "$PWD/check-for-diff" &&
+	test_must_fail git -c commit.verbose=false commit --amend
+'
+
+test_expect_success 'commit.verbose false and --no-verbose' '
+	test_set_editor "$PWD/check-for-diff" &&
+	test_must_fail git -c commit.verbose=false commit --amend --no-verbose
+'
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/218

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

[SZEDER Gábor]

> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.
> 
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> 
> ---
> The previous version of the patch are:
>  - [v8] $gmane/288820
>  - [v7] $gmane/288820
>  - [v6] $gmane/288728
>  - [v5] $gmane/288728
>  - [v4] $gmane/288652
>  - [v3] $gmane/288634
>  - [v2] $gmane/288569
>  - [v1] $gmane/287540
> 
> Changes with respect to the previous patch:
>  - Compare with -1 as only -1 value is used for unspecified behavior.
>  - Write clean tests
> ---
>  Documentation/config.txt     |  4 ++++
>  Documentation/git-commit.txt |  3 ++-
>  builtin/commit.c             | 13 ++++++++++-
>  t/t7507-commit-verbose.sh    | 51 ++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 69 insertions(+), 2 deletions(-)

Please always run the full test suite before submitting patches to
make sure that your changes do not inadvertently break something.
This patch breaks several tests in t7512-status-help.sh,
t7508-status.sh and t7060-wtstatus.sh.

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

On Thu, Mar 24, 2016 at 3:34 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> Add commit.verbose configuration variable as a convenience for those
>> who always prefer --verbose.
>>
>> Helped-by: Junio C Hamano <gitster@pobox.com>
>> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>>
>> ---
>> The previous version of the patch are:
>>  - [v8] $gmane/288820
>>  - [v7] $gmane/288820
>>  - [v6] $gmane/288728
>>  - [v5] $gmane/288728
>>  - [v4] $gmane/288652
>>  - [v3] $gmane/288634
>>  - [v2] $gmane/288569
>>  - [v1] $gmane/287540
>>
>> Changes with respect to the previous patch:
>>  - Compare with -1 as only -1 value is used for unspecified behavior.
>>  - Write clean tests
>> ---
>>  Documentation/config.txt     |  4 ++++
>>  Documentation/git-commit.txt |  3 ++-
>>  builtin/commit.c             | 13 ++++++++++-
>>  t/t7507-commit-verbose.sh    | 51 ++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 69 insertions(+), 2 deletions(-)
>
> Please always run the full test suite before submitting patches to
> make sure that your changes do not inadvertently break something.
> This patch breaks several tests in t7512-status-help.sh,
> t7508-status.sh and t7060-wtstatus.sh.

Sorry for that. I will make sure I do run the complete test suite. I
currently ran only commit based tests. But now that I think about it
that since status and commit share a lot of things, it might be
possible to break parts of status. I will investigate further as to
what cased this problem though I kind of get a hint that it is because
of verbose being the parent and others consuming it. There are a lot
of tests failing.

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

I got it. The verbose is initialised to -1 before. When cmd_commit
runs, it changes the value of verbose accordingly to 0 or positive.
But when cmd_status runs, it will retain the value -1 and the if
clause which accepts all values except 0 will execute. I guess a if
statement inside cmd_status which reinitialises it to 0 or positive
depending on the situation will solve the problem.

On Thu, Mar 24, 2016 at 3:52 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Thu, Mar 24, 2016 at 3:34 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>> Add commit.verbose configuration variable as a convenience for those
>>> who always prefer --verbose.
>>>
>>> Helped-by: Junio C Hamano <gitster@pobox.com>
>>> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>>>
>>> ---
>>> The previous version of the patch are:
>>>  - [v8] $gmane/288820
>>>  - [v7] $gmane/288820
>>>  - [v6] $gmane/288728
>>>  - [v5] $gmane/288728
>>>  - [v4] $gmane/288652
>>>  - [v3] $gmane/288634
>>>  - [v2] $gmane/288569
>>>  - [v1] $gmane/287540
>>>
>>> Changes with respect to the previous patch:
>>>  - Compare with -1 as only -1 value is used for unspecified behavior.
>>>  - Write clean tests
>>> ---
>>>  Documentation/config.txt     |  4 ++++
>>>  Documentation/git-commit.txt |  3 ++-
>>>  builtin/commit.c             | 13 ++++++++++-
>>>  t/t7507-commit-verbose.sh    | 51 ++++++++++++++++++++++++++++++++++++++++++++
>>>  4 files changed, 69 insertions(+), 2 deletions(-)
>>
>> Please always run the full test suite before submitting patches to
>> make sure that your changes do not inadvertently break something.
>> This patch breaks several tests in t7512-status-help.sh,
>> t7508-status.sh and t7060-wtstatus.sh.
>
> Sorry for that. I will make sure I do run the complete test suite. I
> currently ran only commit based tests. But now that I think about it
> that since status and commit share a lot of things, it might be
> possible to break parts of status. I will investigate further as to
> what cased this problem though I kind of get a hint that it is because
> of verbose being the parent and others consuming it. There are a lot
> of tests failing.

[PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

[SZEDER Gábor]

> The reason to make it consider negative values or more specifically
> "unspecified" values is to give the ability to differentiate between
> once, multiple time or with --no-option.
> 
> Eg. :
> initialize verbose = -1
> `git commit` => verbose = -1
> `git commit -v` => verbose = 1
> `git commit -v -v` => verbose = 2
> `git commit --no-verbose` => verbose = 0
> 
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> 
> ---
> The discussion about this patch:
> [1] : http://thread.gmane.org/gmane.comp.version-control.git/289027
> 
> Previous version of the patch:
> [v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061
> 
> Changes introduced:
> Use a different language in commit message to make the change and its
> utility more clear.

I don't see the mentioned change in the commit message.  In
particular:

  - As Eric pointed out in the previous round, the commit message
    misses the single most important point of justification: to
    determine whether '--option' or '--no-option' was specified at
    all.  Explaining this would also make the examples unnecessary.

  - OPT_COUNTUP is used in several places, mostly indirecty, but the
    commit message doesn't explain that possible side-effects to these
    callers were considered and that they are not harmed by this
    change.

> ---
>  Documentation/technical/api-parse-options.txt | 6 ++++--
>  parse-options.c                               | 8 +++++++-
>  2 files changed, 11 insertions(+), 3 deletions(-)

A couple of new tests to t0040-parse-options.sh would be great to
ensure that starting from a negative value works as advertised, i.e.
at least that '--option' jumps to 1 and '--no-option' resets to 0.

> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
> index 5f0757d..a908d8a 100644
> --- a/Documentation/technical/api-parse-options.txt
> +++ b/Documentation/technical/api-parse-options.txt
> @@ -144,8 +144,10 @@ There are some macros to easily define options:
>  
>  `OPT_COUNTUP(short, long, &int_var, description)`::
>  	Introduce a count-up option.
> -	`int_var` is incremented on each use of `--option`, and
> -	reset to zero with `--no-option`.
> +	If the `int_var` is negative and `--option` is absent,
> +	then it will retain its value. Otherwise it will first set
> +	`int_var` to 0 and then increment it on each use of `--option`,
> +	and reset to zero with `--no-option`.
>  
>  `OPT_BIT(short, long, &int_var, description, mask)`::
>  	Introduce a boolean option.
> diff --git a/parse-options.c b/parse-options.c
> index 47a9192..86d30bd 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
>  		return 0;
>  
>  	case OPTION_COUNTUP:
> -		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
> +		if (unset)
> +			*(int *)opt->value = 0;
> +		else {
> +			if (*(int *)opt->value < 0)
> +				*(int *)opt->value = 0;
> +			*(int *)opt->value += 1;
> +		}
>  		return 0;
>  
>  	case OPTION_SET_INT:
> 
> --
> https://github.com/git/git/pull/218
> 
> 

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

[Pranit Bauva]

On Thu, Mar 24, 2016 at 4:03 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> The reason to make it consider negative values or more specifically
>> "unspecified" values is to give the ability to differentiate between
>> once, multiple time or with --no-option.
>>
>> Eg. :
>> initialize verbose = -1
>> `git commit` => verbose = -1
>> `git commit -v` => verbose = 1
>> `git commit -v -v` => verbose = 2
>> `git commit --no-verbose` => verbose = 0
>>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>>
>> ---
>> The discussion about this patch:
>> [1] : http://thread.gmane.org/gmane.comp.version-control.git/289027
>>
>> Previous version of the patch:
>> [v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061
>>
>> Changes introduced:
>> Use a different language in commit message to make the change and its
>> utility more clear.
>
> I don't see the mentioned change in the commit message.  In
> particular:
>
>   - As Eric pointed out in the previous round, the commit message
>     misses the single most important point of justification: to
>     determine whether '--option' or '--no-option' was specified at
>     all.  Explaining this would also make the examples unnecessary.

I will justify it in the commit message. Also will remove the examples.

>   - OPT_COUNTUP is used in several places, mostly indirecty, but the
>     commit message doesn't explain that possible side-effects to these
>     callers were considered and that they are not harmed by this
>     change.

I will include bits from my and Jeff's conversation into this commit message.

>> ---
>>  Documentation/technical/api-parse-options.txt | 6 ++++--
>>  parse-options.c                               | 8 +++++++-
>>  2 files changed, 11 insertions(+), 3 deletions(-)
>
> A couple of new tests to t0040-parse-options.sh would be great to
> ensure that starting from a negative value works as advertised, i.e.
> at least that '--option' jumps to 1 and '--no-option' resets to 0.
>
>> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
>> index 5f0757d..a908d8a 100644
>> --- a/Documentation/technical/api-parse-options.txt
>> +++ b/Documentation/technical/api-parse-options.txt
>> @@ -144,8 +144,10 @@ There are some macros to easily define options:
>>
>>  `OPT_COUNTUP(short, long, &int_var, description)`::
>>       Introduce a count-up option.
>> -     `int_var` is incremented on each use of `--option`, and
>> -     reset to zero with `--no-option`.
>> +     If the `int_var` is negative and `--option` is absent,
>> +     then it will retain its value. Otherwise it will first set
>> +     `int_var` to 0 and then increment it on each use of `--option`,
>> +     and reset to zero with `--no-option`.
>>
>>  `OPT_BIT(short, long, &int_var, description, mask)`::
>>       Introduce a boolean option.
>> diff --git a/parse-options.c b/parse-options.c
>> index 47a9192..86d30bd 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
>>               return 0;
>>
>>       case OPTION_COUNTUP:
>> -             *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>> +             if (unset)
>> +                     *(int *)opt->value = 0;
>> +             else {
>> +                     if (*(int *)opt->value < 0)
>> +                             *(int *)opt->value = 0;
>> +                     *(int *)opt->value += 1;
>> +             }
>>               return 0;
>>
>>       case OPTION_SET_INT:
>>
>> --
>> https://github.com/git/git/pull/218
>>
>>

[PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[SZEDER Gábor]

> Also remove test_set_editor from global scope and use it in whichever
> test it is required.

Why?

test_set_editor sets and exports shell variables.  Since you don't
invoke test_set_editor in a subshell, after the first invocation the
editor will be part of the global scope anyway.

Also missing signoff.

> ---
>  t/t7507-commit-verbose.sh | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> index 2ddf28c..cf95efb 100755
> --- a/t/t7507-commit-verbose.sh
> +++ b/t/t7507-commit-verbose.sh
> @@ -3,12 +3,11 @@
>  test_description='verbose commit template'
>  . ./test-lib.sh
>  
> -cat >check-for-diff <<EOF
> -#!$SHELL_PATH
> -exec grep '^diff --git' "\$1"
> +write_script "check-for-diff" <<-\EOF &&
> +grep '^diff --git' "$1" >out &&
> +test $(wc -l <out) = 1

Our test lib offers the test_line_count helper function, which
outputs a helpful error message in case the number of lines do not
match.

The original didn't check the number of lines.  This change is not
mentioned at all in the commit message.

>  EOF
>  chmod +x check-for-diff
> -test_set_editor "$PWD/check-for-diff"
>  
>  cat >message <<'EOF'
>  subject
> @@ -23,6 +22,7 @@ test_expect_success 'setup' '
>  '
>  
>  test_expect_success 'initial commit shows verbose diff' '
> +	test_set_editor "$PWD/check-for-diff" &&
>  	git commit --amend -v
>  '
>  
> @@ -38,11 +38,13 @@ check_message() {
>  }
>  
>  test_expect_success 'verbose diff is stripped out' '
> +	test_set_editor "$PWD/check-for-diff" &&
>  	git commit --amend -v &&
>  	check_message message
>  '
>  
>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
> +	test_set_editor "$PWD/check-for-diff" &&
>  	git config diff.mnemonicprefix true &&
>  	git commit --amend -v &&
>  	check_message message
> @@ -66,11 +68,13 @@ test_expect_success 'diff in message is retained without -v' '
>  '
>  
>  test_expect_success 'diff in message is retained with -v' '
> +	test_set_editor "$PWD/check-for-diff" &&
>  	git commit --amend -F diff -v &&
>  	check_message diff
>  '
>  
>  test_expect_success 'submodule log is stripped out too with -v' '
> +	test_set_editor "$PWD/check-for-diff" &&
>  	git config diff.submodule log &&
>  	git submodule add ./. sub &&
>  	git commit -m "sub added" &&
> 
> --
> https://github.com/git/git/pull/218
> 

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

[Eric Sunshine]

On Thu, Mar 24, 2016 at 6:33 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> The reason to make it consider negative values or more specifically
>> "unspecified" values is to give the ability to differentiate between
>> once, multiple time or with --no-option.
>>
>> Eg. :
>> initialize verbose = -1
>> `git commit` => verbose = -1
>> `git commit -v` => verbose = 1
>> `git commit -v -v` => verbose = 2
>> `git commit --no-verbose` => verbose = 0
>>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> Changes introduced:
>> Use a different language in commit message to make the change and its
>> utility more clear.
>
> I don't see the mentioned change in the commit message.  In
> particular:
>
>   - As Eric pointed out in the previous round, the commit message
>     misses the single most important point of justification: to
>     determine whether '--option' or '--no-option' was specified at
>     all.  Explaining this would also make the examples unnecessary.

Agreed. It would be more helpful to explain that you are changing
OPT_COUNTUP so that --option always counts up from zero, even if the
initial value was negative, in order to allow the caller to determine
whether --option or --no-option was seen at all, by setting the
initial value to -1 and then checking if it still -1 after
parse_options(). If you explain that well, then the tabular example in
your commit message can go away altogether.

The subject ("make OPTION__COUNTUP consider negative values") could
use a little work too. OPTION__COUNTUP already works with negative
values, but not in the way you want. Instead, you want it to treat
negative values specially as "unspecified", and that's the real gist
of this patch, thus the subject ought, at the very least, have the
word "unspecified" in it.

>   - OPT_COUNTUP is used in several places, mostly indirecty, but the
>     commit message doesn't explain that possible side-effects to these
>     callers were considered and that they are not harmed by this
>     change.
>
>> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
>> @@ -144,8 +144,10 @@ There are some macros to easily define options:
>>  `OPT_COUNTUP(short, long, &int_var, description)`::
>>       Introduce a count-up option.
>> -     `int_var` is incremented on each use of `--option`, and
>> -     reset to zero with `--no-option`.
>> +     If the `int_var` is negative and `--option` is absent,
>> +     then it will retain its value. Otherwise it will first set
>> +     `int_var` to 0 and then increment it on each use of `--option`,
>> +     and reset to zero with `--no-option`.

This reads a little bit backward, but, more importantly, doesn't do a
good job of conveying to the reader that a negative value can
represent "unspecified". The best way to convey that would probably be
via example. For instance, something like this:

    Each use of `--option` increments `int_var`, starting from zero
    (even if initially negative), and `--no-option` resets it to
    zero. To determine if `--option` or `--no-option` was seen at
    all, set `int_var` to a negative value, and if it is still
    negative after parse_options(), then neither `--option` nor
    `--no-option` was seen.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Eric Sunshine]

On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> Also remove test_set_editor from global scope and use it in whichever
>> test it is required.
>
> Why?
>
> test_set_editor sets and exports shell variables.  Since you don't
> invoke test_set_editor in a subshell, after the first invocation the
> editor will be part of the global scope anyway.

Agreed that this needs proper justification in the commit message.
And, the justification is to make each test more self-contained,
particularly because a subsequent patch will introduce a second fake
"editor", and by making tests responsible for setting the editor they
need, they don't have to worry about bad interactions from "editors"
set by earlier tests[1][2].

Another issue is that the commit message is backward. The subject
("t7507-commit-verbose: make test suite use write_script") tries to
sell this as primarily being about write_script(), but the real gist
of the patch is that it is making each test more self-contained, and
the subject should say so. The write_script() bit is just a minor
aside which can be introduced with a "While here let's use
write_script to..." at the end of the commit message.

>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>> index 2ddf28c..cf95efb 100755
>> --- a/t/t7507-commit-verbose.sh
>> +++ b/t/t7507-commit-verbose.sh
>> @@ -3,12 +3,11 @@
>>  test_description='verbose commit template'
>>  . ./test-lib.sh
>>
>> -cat >check-for-diff <<EOF
>> -#!$SHELL_PATH
>> -exec grep '^diff --git' "\$1"
>> +write_script "check-for-diff" <<-\EOF &&
>> +grep '^diff --git' "$1" >out &&
>> +test $(wc -l <out) = 1
>
> Our test lib offers the test_line_count helper function, which
> outputs a helpful error message in case the number of lines do not
> match.

test_line_count() was mentioned in [2], however, this line counting is
done in the fake "editor" script, not in the test script proper, so
the spelled-out form $(wc ...) was proposed[2].

> The original didn't check the number of lines.  This change is not
> mentioned at all in the commit message.

Right, and this particular change really belongs in patch 3/3 where
it's needed[2], and should be properly explained by the 3/3 commit
message.

>>  EOF
>>  chmod +x check-for-diff

Drop the 'chmod' line; write_script() does this for you.

>> -test_set_editor "$PWD/check-for-diff"
>>
>>  cat >message <<'EOF'
>>  subject

[1]: http://article.gmane.org/gmane.comp.version-control.git/289329
[2]: http://article.gmane.org/gmane.comp.version-control.git/289370

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

[Eric Sunshine]

On Thu, Mar 24, 2016 at 4:25 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.

The implementation looks better in this version. A couple comments
below about the test script...

> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> @@ -9,6 +9,12 @@ test $(wc -l <out) = 1
>  EOF
>  chmod +x check-for-diff

Mentioned in patch 2/3 review, this patch (3/3) is where you should
update 'check-for-diff' to also check the line count, and the commit
message should explain the reason for doing so (and don't forget to
mention that it won't harm existing clients of 'check-for-diff').

> +write_script "check-for-double-diff" <<-\EOF &&
> +grep '# Changes not staged for commit' "$1" >out &&
> +test $(wc -l <out) = 2
> +EOF
> +chmod +x check-for-double-diff

Also mentioned in patch 2/3 review: drop 'chmod'; write_script() does
it for you.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Pranit Bauva]

On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>> Also remove test_set_editor from global scope and use it in whichever
>>> test it is required.
>>
>> Why?
>>
>> test_set_editor sets and exports shell variables.  Since you don't
>> invoke test_set_editor in a subshell, after the first invocation the
>> editor will be part of the global scope anyway.
>
> Agreed that this needs proper justification in the commit message.
> And, the justification is to make each test more self-contained,
> particularly because a subsequent patch will introduce a second fake
> "editor", and by making tests responsible for setting the editor they
> need, they don't have to worry about bad interactions from "editors"
> set by earlier tests[1][2].

This shou  cadve  mbe ave be ave be ave be ave be ave be ave be ave
> Another issue is that the commit message is backward. The subject
> ("t7507-commit-verbose: make test suite use write_script") tries to
> sell this as primarily being about write_script(), but the real gist
> of the patch is that it is making each test more self-contained, and
> the subject should say so. The write_script() bit is just a minor
> aside which can be introduced with a "While here let's use
> write_script to..." at the end of the commit message.
>
>>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>>> index 2ddf28c..cf95efb 100755
>>> --- a/t/t7507-commit-verbose.sh
>>> +++ b/t/t7507-commit-verbose.sh
>>> @@ -3,12 +3,11 @@
>>>  test_description='verbose commit template'
>>>  . ./test-lib.sh
>>>
>>> -cat >check-for-diff <<EOF
>>> -#!$SHELL_PATH
>>> -exec grep '^diff --git' "\$1"
>>> +write_script "check-for-diff" <<-\EOF &&
>>> +grep '^diff --git' "$1" >out &&
>>> +test $(wc -l <out) = 1
>>
>> Our test lib offers the test_line_count helper function, which
>> outputs a helpful error message in case the number of lines do not
>> match.
>
> test_line_count() was mentioned in [2], however, this line counting is
> done in the fake "editor" script, not in the test script proper, so
> the spelled-out form $(wc ...) was proposed[2].

I have a slight doubt regarding this. Can the functions from test-lib
work in such scripts flawlessly? If yes, then its probably better to
use them.

>> The original didn't check the number of lines.  This change is not
>> mentioned at all in the commit message.
>
> Right, and this particular change really belongs in patch 3/3 where
> it's needed[2], and should be properly explained by the 3/3 commit
> message.

Sure! It should have been mentioned.

>>>  EOF
>>>  chmod +x check-for-diff
>
> Drop the 'chmod' line; write_script() does this for you.

I was unaware about this. I will drop it off.

>>> -test_set_editor "$PWD/check-for-diff"
>>>
>>>  cat >message <<'EOF'
>>>  subject
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/289329
> [2]: http://article.gmane.org/gmane.comp.version-control.git/289370

Re: [PATCH v9 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

On Fri, Mar 25, 2016 at 5:35 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Thu, Mar 24, 2016 at 4:25 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Add commit.verbose configuration variable as a convenience for those
>> who always prefer --verbose.
>
> The implementation looks better in this version. A couple comments
> below about the test script...
>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>> @@ -9,6 +9,12 @@ test $(wc -l <out) = 1
>>  EOF
>>  chmod +x check-for-diff
>
> Mentioned in patch 2/3 review, this patch (3/3) is where you should
> update 'check-for-diff' to also check the line count, and the commit
> message should explain the reason for doing so (and don't forget to
> mention that it won't harm existing clients of 'check-for-diff').

Agree that check the line count should belong to this patch. And will
add more details in the commit message.

>> +write_script "check-for-double-diff" <<-\EOF &&
>> +grep '# Changes not staged for commit' "$1" >out &&
>> +test $(wc -l <out) = 2
>> +EOF
>> +chmod +x check-for-double-diff
>
> Also mentioned in patch 2/3 review: drop 'chmod'; write_script() does
> it for you.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Eric Sunshine]

On Fri, Mar 25, 2016 at 2:06 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> Agreed that this needs proper justification in the commit message.
>> And, the justification is to make each test more self-contained,
>> particularly because a subsequent patch will introduce a second fake
>> "editor", and by making tests responsible for setting the editor they
>> need, they don't have to worry about bad interactions from "editors"
>> set by earlier tests[1][2].
>
> This shou  cadve  mbe ave be ave be ave be ave be ave be ave be ave

Hmm, yes, what you say makes perfect sense... er, wait...

>>>> -cat >check-for-diff <<EOF
>>>> -#!$SHELL_PATH
>>>> -exec grep '^diff --git' "\$1"
>>>> +write_script "check-for-diff" <<-\EOF &&
>>>> +grep '^diff --git' "$1" >out &&
>>>> +test $(wc -l <out) = 1
>>>
>>> Our test lib offers the test_line_count helper function, which
>>> outputs a helpful error message in case the number of lines do not
>>> match.
>>
>> test_line_count() was mentioned in [2], however, this line counting is
>> done in the fake "editor" script, not in the test script proper, so
>> the spelled-out form $(wc ...) was proposed[2].
>
> I have a slight doubt regarding this. Can the functions from test-lib
> work in such scripts flawlessly? If yes, then its probably better to
> use them.

Probably not easily, and it's not worth complicating the "editor"
script by trying to import the test_line_count() function.

>>>>  chmod +x check-for-diff
>>
>> Drop the 'chmod' line; write_script() does this for you.
>
> I was unaware about this. I will drop it off.

I thought I had mentioned it in the review in which I had suggested
using write_script() or one of the follow-up emails, but upon looking
back at those messages, I saw it was not so. It turns out that I was
probably thinking about a different patch review in which I had
mentioned dropping 'chmod'[1].

[1]: http://article.gmane.org/gmane.comp.version-control.git/288085/

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Pranit Bauva]

On Fri, Mar 25, 2016 at 11:54 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Fri, Mar 25, 2016 at 2:06 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Fri, Mar 25, 2016 at 5:27 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> Agreed that this needs proper justification in the commit message.
>>> And, the justification is to make each test more self-contained,
>>> particularly because a subsequent patch will introduce a second fake
>>> "editor", and by making tests responsible for setting the editor they
>>> need, they don't have to worry about bad interactions from "editors"
>>> set by earlier tests[1][2].
>>
>> This shou  cadve  mbe ave be ave be ave be ave be ave be ave be ave
>
> Hmm, yes, what you say makes perfect sense... er, wait...

haha :) Sorry for this. My browser crashed and it sent out some crap
(don't know how). I mean to say, "This should have been mentioned in
the commit message that scope of editor is reduced so as to not worry
about bad interactions from other "editors" which may be used after
wards."
>
>>>>> -cat >check-for-diff <<EOF
>>>>> -#!$SHELL_PATH
>>>>> -exec grep '^diff --git' "\$1"
>>>>> +write_script "check-for-diff" <<-\EOF &&
>>>>> +grep '^diff --git' "$1" >out &&
>>>>> +test $(wc -l <out) = 1
>>>>
>>>> Our test lib offers the test_line_count helper function, which
>>>> outputs a helpful error message in case the number of lines do not
>>>> match.
>>>
>>> test_line_count() was mentioned in [2], however, this line counting is
>>> done in the fake "editor" script, not in the test script proper, so
>>> the spelled-out form $(wc ...) was proposed[2].
>>
>> I have a slight doubt regarding this. Can the functions from test-lib
>> work in such scripts flawlessly? If yes, then its probably better to
>> use them.
>
> Probably not easily, and it's not worth complicating the "editor"
> script by trying to import the test_line_count() function.

Sure!

>>>>>  chmod +x check-for-diff
>>>
>>> Drop the 'chmod' line; write_script() does this for you.
>>
>> I was unaware about this. I will drop it off.
>
> I thought I had mentioned it in the review in which I had suggested
> using write_script() or one of the follow-up emails, but upon looking
> back at those messages, I saw it was not so. It turns out that I was
> probably thinking about a different patch review in which I had
> mentioned dropping 'chmod'[1].
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/288085/
Oh! I hadn't tested by removing chmod. I will try it for fun.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[SZEDER Gábor]

Quoting Eric Sunshine <sunshine@sunshineco.com>:

> On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:

>>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>>> index 2ddf28c..cf95efb 100755
>>> --- a/t/t7507-commit-verbose.sh
>>> +++ b/t/t7507-commit-verbose.sh
>>> @@ -3,12 +3,11 @@
>>>  test_description='verbose commit template'
>>>  . ./test-lib.sh
>>>
>>> -cat >check-for-diff <<EOF
>>> -#!$SHELL_PATH
>>> -exec grep '^diff --git' "\$1"
>>> +write_script "check-for-diff" <<-\EOF &&
>>> +grep '^diff --git' "$1" >out &&
>>> +test $(wc -l <out) = 1
>>
>> Our test lib offers the test_line_count helper function, which
>> outputs a helpful error message in case the number of lines do not
>> match.
>
> test_line_count() was mentioned in [2], however, this line counting is
> done in the fake "editor" script, not in the test script proper, so
> the spelled-out form $(wc ...) was proposed[2].

Ah, yes, of course.

But then the question is: why is the line counting in the editor script
in the first place?

By redirecting grep's output to a file in the editor script, like this
patch wanted to, we can count the lines in the test script itself after
'git commit' finished.  This way we could use test_line_count, with
all its error reporting benefits, and we could use the same editor
script for all tests.

And if you insist on doing the line counting in the editor script, then
why redirecting grep's output and 'wc -l' separately, why not 'grep -c'?

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Pranit Bauva]

On Fri, Mar 25, 2016 at 8:16 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:

> By redirecting grep's output to a file in the editor script, like this
> patch wanted to, we can count the lines in the test script itself after
> 'git commit' finished.  This way we could use test_line_count, with
> all its error reporting benefits, and we could use the same editor
> script for all tests.
>
> And if you insist on doing the line counting in the editor script, then
> why redirecting grep's output and 'wc -l' separately, why not 'grep -c'?

Nice way. Hadn't thought of this before. This will also eliminate
having 2 different scripts to test for 1 line and other to test for 2
lines.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Eric Sunshine]

On Fri, Mar 25, 2016 at 10:46 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Quoting Eric Sunshine <sunshine@sunshineco.com>:
>> On Thu, Mar 24, 2016 at 7:00 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>>> -cat >check-for-diff <<EOF
>>>> -#!$SHELL_PATH
>>>> -exec grep '^diff --git' "\$1"
>>>> +write_script "check-for-diff" <<-\EOF &&
>>>> +grep '^diff --git' "$1" >out &&
>>>> +test $(wc -l <out) = 1
>>>
>>> Our test lib offers the test_line_count helper function, which
>>> outputs a helpful error message in case the number of lines do not
>>> match.
>>
>> test_line_count() was mentioned in [2], however, this line counting is
>> done in the fake "editor" script, not in the test script proper, so
>> the spelled-out form $(wc ...) was proposed[2].
>
> Ah, yes, of course.
>
> But then the question is: why is the line counting in the editor script
> in the first place?
>
> By redirecting grep's output to a file in the editor script, like this
> patch wanted to, we can count the lines in the test script itself after
> 'git commit' finished.  This way we could use test_line_count, with
> all its error reporting benefits, and we could use the same editor
> script for all tests.

That works too, simplifying the overall implementation, and
eliminating the need for the introductory patch which moves
'test_set_editor' into each test.

> And if you insist on doing the line counting in the editor script, then
> why redirecting grep's output and 'wc -l' separately, why not 'grep -c'?

Ugh, I utterly forgot about -c.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Pranit Bauva]

On Fri, Mar 25, 2016 at 10:34 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:

> That works too, simplifying the overall implementation, and
> eliminating the need for the introductory patch which moves
> 'test_set_editor' into each test.

Wouldn't it be cleaner if the introductory patch contain:
1. using write_script()
2. grep the output to a file
3. test for no of lines=1 in required tests
?

Then the patch 3/3
>> And if you insist on doing the line counting in the editor script, then
>> why redirecting grep's output and 'wc -l' separately, why not 'grep -c'?
>
> Ugh, I utterly forgot about -c.

Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script

[Eric Sunshine]

On Fri, Mar 25, 2016 at 2:15 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 10:34 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> That works too, simplifying the overall implementation, and
>> eliminating the need for the introductory patch which moves
>> 'test_set_editor' into each test.
>
> Wouldn't it be cleaner if the introductory patch contain:
> 1. using write_script()
> 2. grep the output to a file
> 3. test for no of lines=1 in required tests
> ?

You could do that.

[PATCH v10 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose taking care of multiple levels of verbosity.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:
 - [v9] $gmane/288820
 - [v8] $gmane/288820
 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

Changes with respect to the previous patch:
 - Fixed a status related bug pointed out by SZEDER
 - Change some tests
---
 Documentation/config.txt     |  4 ++++
 Documentation/git-commit.txt |  3 ++-
 builtin/commit.c             | 16 ++++++++++++++-
 t/t7507-commit-verbose.sh    | 48 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..6a80a38 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1355,6 +1357,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	finalize_colopts(&s.colopts, -1);
 	finalize_deferred_config(&s);
 
+	if (verbose == -1)
+		verbose = 0;
+
 	handle_untracked_files_arg(&s);
 	if (show_ignored_in_status)
 		s.show_ignored_files = 1;
@@ -1505,6 +1510,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1664,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+
+	if (verbose == -1)
+		verbose = (config_verbose == -1) ? 0 : config_verbose;
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index b40eb3c..569fd8b 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -101,4 +101,52 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'commit.verbose true and --verbose omitted' '
+	echo content >file2 &&
+	echo content >>file &&
+	git add file2 &&
+	git -c commit.verbose=true commit -F message &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose true and --verbose' '
+	git -c commit.verbose=true commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose true and -v -v' '
+	git -c commit.verbose=true commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose true and --no-verbose' '
+	git -c commit.verbose=true commit --amend --no-verbose &&
+	! test -s out
+'
+
+test_expect_success 'commit.verbose false and --verbose' '
+	git -c commit.verbose=false commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose false and -v -v' '
+	git -c commit.verbose=false commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose false and --verbose omitted' '
+	git -c commit.verbose=false commit --amend &&
+	! test -s out
+'
+
+test_expect_success 'commit.verbose false and --no-verbose' '
+	git -c commit.verbose=false commit --amend --no-verbose &&
+	! test -s out
+'
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/218

[PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Pranit Bauva]

So that we can see how many diffs were contained in the message and use
them in individual tests where ever it is required. Also use
write_script() to create the fake "editor".

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
 t/t7507-commit-verbose.sh | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..b40eb3c 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -3,9 +3,11 @@
 test_description='verbose commit template'
 . ./test-lib.sh
 
-cat >check-for-diff <<EOF
-#!$SHELL_PATH
-exec grep '^diff --git' "\$1"
+write_script "check-for-diff" <<'EOF' &&
+! test -s out ||
+rm out &&
+! grep '^diff --git' "$1" ||
+grep '^diff --git' "$1" >out
 EOF
 chmod +x check-for-diff
 test_set_editor "$PWD/check-for-diff"
@@ -23,7 +25,8 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'initial commit shows verbose diff' '
-	git commit --amend -v
+	git commit --amend -v &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'second commit' '
@@ -39,13 +42,15 @@ check_message() {
 
 test_expect_success 'verbose diff is stripped out' '
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
 	git config diff.mnemonicprefix true &&
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 cat >diff <<'EOF'

--
https://github.com/git/git/pull/218

[PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values

[Pranit Bauva]

The reason to make it understand negative values or more specifically
"unspecified" values is to give the ability to differentiate whether
`--option` or `--no-option` was specified at all.

Many uses of COUNTUP have now been replaced with BOOL and what remains
are verbose/quiet/force. This change will not affect existing users of
COUNTUP at all, as long as they use the initial value of 0 (or more), as
there is no mechanism to decrement. The only thing the command line can
do is to reset it to zero with "--no-foo".

Verbose or quiet don't use negative values before this commit but force
uses it in a different way to handle its config and then munges the "-1"
into 0 before we get to parse_options.

There are uses of COUNTUP in cmd_hash_object() and test-parse-options.c
and they are both fine.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes introduced:
Use a different language in commit message to make the change and its
utility more clear. Also added some points as to where this patch could
break but it doesn't.
---
 Documentation/technical/api-parse-options.txt | 8 ++++++--
 parse-options.c                               | 8 +++++++-
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..8908bf7 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,12 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	Each use of `--option` increments `int_var`, starting from zero
+	(even if initially negative), and `--no-option` resets it to
+	zero. To determine if `--option` or `--no-option` was set at
+	all, set `int_var` to a negative value, and if it is still
+	negative after parse_options(), then neither `--option` nor
+	`--no-option` was seen.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..86d30bd 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
-		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
+		if (unset)
+			*(int *)opt->value = 0;
+		else {
+			if (*(int *)opt->value < 0)
+				*(int *)opt->value = 0;
+			*(int *)opt->value += 1;
+		}
 		return 0;
 
 	case OPTION_SET_INT:

--
https://github.com/git/git/pull/218

Re: [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values

[Eric Sunshine]

On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> parse-options.c: make OPTION__COUNTUP understand "unspecified" values

A bit clearer: s/understand/respect/
Also: s/__/_/

> The reason to make it understand negative values or more specifically
> "unspecified" values is to give the ability to differentiate whether
> `--option` or `--no-option` was specified at all.

The word "negative" shows up far too early in this paragraph, even
before "unspecified". It also fails utterly to explain what
"unspecified" means and how to use it. It does vaguely explain why
respecting "unspecified" is desirable (to know if --[no-]option was
seen), but otherwise leaves the reader quite clueless.

> Many uses of COUNTUP have now been replaced with BOOL and what remains
> are verbose/quiet/force. This change will not affect existing users of
> COUNTUP at all, as long as they use the initial value of 0 (or more), as
> there is no mechanism to decrement. The only thing the command line can
> do is to reset it to zero with "--no-foo".

Copying this paragraph verbatim from Junio's email[1] isn't
necessarily the best way to compose a commit message. Junio was
"thinking out loud" while justifying the change to himself as being
safe, but you ought to reframe this reasoning into a more concise form
which flows with the rest of the commit message, keeping the important
bits and dropping others.

> Verbose or quiet don't use negative values before this commit but force
> uses it in a different way to handle its config and then munges the "-1"
> into 0 before we get to parse_options.

Presumably, you're talking about a very specific instance of -1 in
conjunction with OPT__FORCE in builtin/clean.c, but that information
is entirely missing from this paragraph, thus this explanation serves
only to confuse rather than clarify. It is a good idea to cite this
specific unusual case when justifying that this change is safe, but it
must be accompanied by sufficient context for the reader to understand
what is being said.

> There are uses of COUNTUP in cmd_hash_object() and test-parse-options.c
> and they are both fine.

What does "fine" mean? I know from reading the code that "fine" means
that these clients initialize the values to 0, thus should see no
behavioral difference. But why are these two cases called out
specially when they are already covered by the above "as long as they
use initial value of 0" explanation? As a reader, having these two
cases mentioned specially makes me wonder if I'm missing something
non-obvious about them.

It would probably be better to avoid mentioning cmd_hash_object() and
test-parse-options.c at all, and instead explain generally that, with
one exception (builtin/clean.c), all current clients of OPTION_COUNTUP
use an initial value of zero, thus are not impacted by this change.
And, then go on to explain builtin/clean.c's special case and why it
is safe, as well.


Sorry for seeming to be very picky, but if I hadn't already been
following this topic (and hadn't in fact suggested this particular
change), as a reader, I think I would find this commit message utterly
baffling, and wouldn't have a clue what this change is about or why it
is desirable.

Perhaps it would be a good idea to re-read "(2) Describe your changes
well" in Documentation/SubmittingPatches for hints about writing a
good commit message, as well as Junio's recent re-stating[2] of those
hints.

Try to write the commit message as if you were speaking to someone who
wasn't already familiar with the issue you're trying to solve.
Specifically, explain the problem ("no way to distinguish between
--[no-]option being seen or not"); explain the solution ("introduce an
'unspecified' value"); the implementation of the "unspecified" value
("any negative number" plus an example of how to make use of it);
justify that the change is safe ("existing clients of OPTION_COUNTUP
are not impacted because ...").

> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> The discussion about this patch:
> [1] : http://thread.gmane.org/gmane.comp.version-control.git/289027
>
> Previous version of the patch:
> [v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Unless I'm mistaken, the previous version was v9[3], not v1.

> Changes introduced:
> Use a different language in commit message to make the change and its
> utility more clear. Also added some points as to where this patch could
> break but it doesn't.

This version forgets to add the new tests to t0040-parse-options.sh
which SZEDER requested[4] to ensure that the new behavior works as
expected.

> ---
> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
> @@ -144,8 +144,12 @@ There are some macros to easily define options:
>
>  `OPT_COUNTUP(short, long, &int_var, description)`::
>         Introduce a count-up option.
> -       `int_var` is incremented on each use of `--option`, and
> -       reset to zero with `--no-option`.
> +       Each use of `--option` increments `int_var`, starting from zero
> +       (even if initially negative), and `--no-option` resets it to
> +       zero. To determine if `--option` or `--no-option` was set at
> +       all, set `int_var` to a negative value, and if it is still

I realize that you copied this text verbatim from the example I
gave[5], but in retrospect, I think s/set/initialize/ would be a bit
more clear:

    all, initialize `int_var` to a negative value, ...

> +       negative after parse_options(), then neither `--option` nor
> +       `--no-option` was seen.

[1]: http://article.gmane.org/gmane.comp.version-control.git/289264/
[2]: http://article.gmane.org/gmane.comp.version-control.git/289757/
[3]: http://thread.gmane.org/gmane.comp.version-control.git/288820/focus=289724
[4]: http://article.gmane.org/gmane.comp.version-control.git/289733
[5]: http://article.gmane.org/gmane.comp.version-control.git/289822

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Eric Sunshine]

On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> So that we can see how many diffs were contained in the message and use
> them in individual tests where ever it is required. Also use
> write_script() to create the fake "editor".

It is important to explain *why* you want to be able to count how many
diffs were in the editor message. In particular, you will be adding
new tests in a subsequent patch which will expect a specific number of
diffs (rather than any number of diffs)

Also, you need to explain why you're changing the existing tests to
count the number of diffs. Is it simply "because you can" or is it
because you suspect that a change you're making in a subsequent patch
might accidentally cause too many diffs to show up in the existing
test cases?

> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> @@ -3,9 +3,11 @@
> -cat >check-for-diff <<EOF
> -#!$SHELL_PATH
> -exec grep '^diff --git' "\$1"
> +write_script "check-for-diff" <<'EOF' &&

The 'EOF' is more commonly written as \EOF in Git test scripts.

> +! test -s out ||
> +rm out &&

Why not just "rm -f out"? But, more importantly, why do you need to
remove the file at all? The '>' redirection operator (used below) will
overwrite the file, so no need to remove it beforehand.

> +! grep '^diff --git' "$1" ||
> +grep '^diff --git' "$1" >out

Um, what? Why two greps? I would have expected you to simply re-use
the existing grep (minus the backslash) while adding the redirection:

    -exec grep '^diff --git' "\$1"
    +exec grep '^diff --git' "$1" >out

Am I missing something obvious?

>  EOF
>  chmod +x check-for-diff

Mentioned previously[1]: Drop the 'chmod' since write_script() does it for you.

[1]: http://article.gmane.org/gmane.comp.version-control.git/289832

>  test_set_editor "$PWD/check-for-diff"
> @@ -23,7 +25,8 @@ test_expect_success 'setup' '
>  test_expect_success 'initial commit shows verbose diff' '
> -       git commit --amend -v
> +       git commit --amend -v &&
> +       test_line_count = 1 out
>  '
>
>  test_expect_success 'second commit' '
> @@ -39,13 +42,15 @@ check_message() {
>
>  test_expect_success 'verbose diff is stripped out' '
>         git commit --amend -v &&
> -       check_message message
> +       check_message message &&
> +       test_line_count = 1 out
>  '
>
>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
>         git config diff.mnemonicprefix true &&
>         git commit --amend -v &&
> -       check_message message
> +       check_message message &&
> +       test_line_count = 1 out
>  '

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Eric Sunshine]

On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose taking care of multiple levels of verbosity.

What does "taking care of multiple levels of verbosity" mean? I
suppose you mean that commit.verbose specifies a verbosity level
(rather than being merely boolean), but that phrase is difficult to
decipher. And, since it's obvious from the patch itself that verbosity
is not a mere boolean, there isn't really a need to mention it here.
The commit message would be perfectly fine without that bit, so
perhaps just drop it.

> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>
> ---
> Changes with respect to the previous patch:
>  - Fixed a status related bug pointed out by SZEDER
>  - Change some tests

Please help reviewers out by being a bit more verbose when describing
the changes. For instance, what bug did you fix pointed out by SZEDER?
And, "change some tests" says nothing useful. What did you change in
the tests?

> ---
> diff --git a/builtin/commit.c b/builtin/commit.c
> @@ -1355,6 +1357,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
>         finalize_colopts(&s.colopts, -1);
>         finalize_deferred_config(&s);
>
> +       if (verbose == -1)
> +               verbose = 0;
> +

Nit: It might be good to drop the blank line above this new
conditional to make it clear that it is part of the
init_config/parse_options processing (the tail of which is visible in
the context above).

>         handle_untracked_files_arg(&s);
>         if (show_ignored_in_status)
>                 s.show_ignored_files = 1;
> @@ -1654,6 +1664,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>         argc = parse_and_validate_options(argc, argv, builtin_commit_options,
>                                           builtin_commit_usage,
>                                           prefix, current_head, &s);
> +
> +       if (verbose == -1)
> +               verbose = (config_verbose == -1) ? 0 : config_verbose;
> +

Nit: For consistency, dropping the blank line above this new
conditional wouldn't hurt either.

>         if (dry_run)
>                 return dry_run_commit(argc, argv, prefix, current_head, &s);
>         index_file = prepare_index(argc, argv, prefix, current_head, 0);
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> @@ -101,4 +101,52 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
> +test_expect_success 'commit.verbose true and --verbose omitted' '
> +       echo content >file2 &&
> +       echo content >>file &&
> +       git add file2 &&
> +       git -c commit.verbose=true commit -F message &&
> +       test_line_count = 1 out
> +'

Why is this test so utterly different than it was in v9 (even though
the title is the same), and why is it so different from other tests
below?

More below...

> +test_expect_success 'commit.verbose true and --verbose' '
> +       git -c commit.verbose=true commit --amend --verbose &&
> +       test_line_count = 1 out
> +'
> +
> +test_expect_success 'commit.verbose true and -v -v' '
> +       git -c commit.verbose=true commit --amend -v -v &&
> +       test_line_count = 2 out
> +'
> +
> +test_expect_success 'commit.verbose true and --no-verbose' '
> +       git -c commit.verbose=true commit --amend --no-verbose &&
> +       ! test -s out
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose' '
> +       git -c commit.verbose=false commit --amend --verbose &&
> +       test_line_count = 1 out
> +'
> +
> +test_expect_success 'commit.verbose false and -v -v' '
> +       git -c commit.verbose=false commit --amend -v -v &&
> +       test_line_count = 2 out
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose omitted' '
> +       git -c commit.verbose=false commit --amend &&
> +       ! test -s out
> +'
> +
> +test_expect_success 'commit.verbose false and --no-verbose' '
> +       git -c commit.verbose=false commit --amend --no-verbose &&
> +       ! test -s out
> +'
> +
> +test_expect_success 'status ignores commit.verbose=true' '
> +       git -c commit.verbose=true status >actual &&
> +       ! grep "^diff --git" actual
> +'

The fact that v9 broke a number of tests in other scripts which use
git-status (as SZEDER pointed out[1]), due to initializing 'verbose'
to -1 in builtin/commit.c, suggests that you probably ought to add
another test here to protect against that sort of breakage, as well.
Specifically, git-status should remain non-verbose when neither
commit.verbose nor --verbose is specified.

> +
>  test_done

Re: [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values

[Pranit Bauva]

On Sun, Mar 27, 2016 at 8:15 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> parse-options.c: make OPTION__COUNTUP understand "unspecified" values
>
> A bit clearer: s/understand/respect/
> Also: s/__/_/

Sure.

>> The reason to make it understand negative values or more specifically
>> "unspecified" values is to give the ability to differentiate whether
>> `--option` or `--no-option` was specified at all.
>
> The word "negative" shows up far too early in this paragraph, even
> before "unspecified". It also fails utterly to explain what
> "unspecified" means and how to use it. It does vaguely explain why
> respecting "unspecified" is desirable (to know if --[no-]option was
> seen), but otherwise leaves the reader quite clueless.
>
>> Many uses of COUNTUP have now been replaced with BOOL and what remains
>> are verbose/quiet/force. This change will not affect existing users of
>> COUNTUP at all, as long as they use the initial value of 0 (or more), as
>> there is no mechanism to decrement. The only thing the command line can
>> do is to reset it to zero with "--no-foo".
>
> Copying this paragraph verbatim from Junio's email[1] isn't
> necessarily the best way to compose a commit message. Junio was
> "thinking out loud" while justifying the change to himself as being
> safe, but you ought to reframe this reasoning into a more concise form
> which flows with the rest of the commit message, keeping the important
> bits and dropping others.

I will drop off some initial parts.

>> Verbose or quiet don't use negative values before this commit but force
>> uses it in a different way to handle its config and then munges the "-1"
>> into 0 before we get to parse_options.
>
> Presumably, you're talking about a very specific instance of -1 in
> conjunction with OPT__FORCE in builtin/clean.c, but that information
> is entirely missing from this paragraph, thus this explanation serves
> only to confuse rather than clarify. It is a good idea to cite this
> specific unusual case when justifying that this change is safe, but it
> must be accompanied by sufficient context for the reader to understand
> what is being said.

I will mention about OPT__FORCE in builtin/clean.c clearly.

>> There are uses of COUNTUP in cmd_hash_object() and test-parse-options.c
>> and they are both fine.
>
> What does "fine" mean? I know from reading the code that "fine" means
> that these clients initialize the values to 0, thus should see no
> behavioral difference. But why are these two cases called out
> specially when they are already covered by the above "as long as they
> use initial value of 0" explanation? As a reader, having these two
> cases mentioned specially makes me wonder if I'm missing something
> non-obvious about them.

Its good to drop off this paragraph

> It would probably be better to avoid mentioning cmd_hash_object() and
> test-parse-options.c at all, and instead explain generally that, with
> one exception (builtin/clean.c), all current clients of OPTION_COUNTUP
> use an initial value of zero, thus are not impacted by this change.
> And, then go on to explain builtin/clean.c's special case and why it
> is safe, as well.
>
>
> Sorry for seeming to be very picky, but if I hadn't already been
> following this topic (and hadn't in fact suggested this particular
> change), as a reader, I think I would find this commit message utterly
> baffling, and wouldn't have a clue what this change is about or why it
> is desirable.
>
> Perhaps it would be a good idea to re-read "(2) Describe your changes
> well" in Documentation/SubmittingPatches for hints about writing a
> good commit message, as well as Junio's recent re-stating[2] of those
> hints.

I don't disagree to your point and it is a bit difficult for me to
explain stuff to other people especially when I know what's going on
but other might not.

> Try to write the commit message as if you were speaking to someone who
> wasn't already familiar with the issue you're trying to solve.
> Specifically, explain the problem ("no way to distinguish between
> --[no-]option being seen or not"); explain the solution ("introduce an
> 'unspecified' value"); the implementation of the "unspecified" value
> ("any negative number" plus an example of how to make use of it);
> justify that the change is safe ("existing clients of OPTION_COUNTUP
> are not impacted because ...").

I will try and do this in the commit message.

>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> The discussion about this patch:
>> [1] : http://thread.gmane.org/gmane.comp.version-control.git/289027
>>
>> Previous version of the patch:
>> [v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061
>
> Unless I'm mistaken, the previous version was v9[3], not v1.
>
>> Changes introduced:
>> Use a different language in commit message to make the change and its
>> utility more clear. Also added some points as to where this patch could
>> break but it doesn't.
>
> This version forgets to add the new tests to t0040-parse-options.sh
> which SZEDER requested[4] to ensure that the new behavior works as
> expected.
>
>> ---
>> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
>> @@ -144,8 +144,12 @@ There are some macros to easily define options:
>>
>>  `OPT_COUNTUP(short, long, &int_var, description)`::
>>         Introduce a count-up option.
>> -       `int_var` is incremented on each use of `--option`, and
>> -       reset to zero with `--no-option`.
>> +       Each use of `--option` increments `int_var`, starting from zero
>> +       (even if initially negative), and `--no-option` resets it to
>> +       zero. To determine if `--option` or `--no-option` was set at
>> +       all, set `int_var` to a negative value, and if it is still
>
> I realize that you copied this text verbatim from the example I
> gave[5], but in retrospect, I think s/set/initialize/ would be a bit
> more clear:
>
>     all, initialize `int_var` to a negative value, ...
>
>> +       negative after parse_options(), then neither `--option` nor
>> +       `--no-option` was seen.
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/289264/
> [2]: http://article.gmane.org/gmane.comp.version-control.git/289757/
> [3]: http://thread.gmane.org/gmane.comp.version-control.git/288820/focus=289724
> [4]: http://article.gmane.org/gmane.comp.version-control.git/289733
> [5]: http://article.gmane.org/gmane.comp.version-control.git/289822

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

On Sun, Mar 27, 2016 at 9:04 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Add commit.verbose configuration variable as a convenience for those
>> who always prefer --verbose taking care of multiple levels of verbosity.
>
> What does "taking care of multiple levels of verbosity" mean? I
> suppose you mean that commit.verbose specifies a verbosity level
> (rather than being merely boolean), but that phrase is difficult to
> decipher. And, since it's obvious from the patch itself that verbosity
> is not a mere boolean, there isn't really a need to mention it here.
> The commit message would be perfectly fine without that bit, so
> perhaps just drop it.

I will drop it.

>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>>
>> ---
>> Changes with respect to the previous patch:
>>  - Fixed a status related bug pointed out by SZEDER
>>  - Change some tests
>
> Please help reviewers out by being a bit more verbose when describing
> the changes. For instance, what bug did you fix pointed out by SZEDER?
> And, "change some tests" says nothing useful. What did you change in
> the tests?

I will try and be more specific henceforth.

>> ---
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> @@ -1355,6 +1357,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
>>         finalize_colopts(&s.colopts, -1);
>>         finalize_deferred_config(&s);
>>
>> +       if (verbose == -1)
>> +               verbose = 0;
>> +
>
> Nit: It might be good to drop the blank line above this new
> conditional to make it clear that it is part of the
> init_config/parse_options processing (the tail of which is visible in
> the context above).

Sure.

>>         handle_untracked_files_arg(&s);
>>         if (show_ignored_in_status)
>>                 s.show_ignored_files = 1;
>> @@ -1654,6 +1664,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>>         argc = parse_and_validate_options(argc, argv, builtin_commit_options,
>>                                           builtin_commit_usage,
>>                                           prefix, current_head, &s);
>> +
>> +       if (verbose == -1)
>> +               verbose = (config_verbose == -1) ? 0 : config_verbose;
>> +
>
> Nit: For consistency, dropping the blank line above this new
> conditional wouldn't hurt either.
>
>>         if (dry_run)
>>                 return dry_run_commit(argc, argv, prefix, current_head, &s);
>>         index_file = prepare_index(argc, argv, prefix, current_head, 0);
>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>> @@ -101,4 +101,52 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
>> +test_expect_success 'commit.verbose true and --verbose omitted' '
>> +       echo content >file2 &&
>> +       echo content >>file &&
>> +       git add file2 &&
>> +       git -c commit.verbose=true commit -F message &&
>> +       test_line_count = 1 out
>> +'
>
> Why is this test so utterly different than it was in v9 (even though
> the title is the same), and why is it so different from other tests
> below?

This is because the "editor" in v9 checked for "# Changes"... While
this "editor" checks for 'diff --git'. And submodules don't give a
proper diff to verify (I tried this out and noticed this behavior by
tweaking some parts). In fact submodules don't give diff at all. But
they do give "# Changes"... So its important to setup up a little
before getting started. If this seems unnecessary, then should I move
all the tests which were introduced here above the submodule test?

> More below...
>
>> +test_expect_success 'commit.verbose true and --verbose' '
>> +       git -c commit.verbose=true commit --amend --verbose &&
>> +       test_line_count = 1 out
>> +'
>> +
>> +test_expect_success 'commit.verbose true and -v -v' '
>> +       git -c commit.verbose=true commit --amend -v -v &&
>> +       test_line_count = 2 out
>> +'
>> +
>> +test_expect_success 'commit.verbose true and --no-verbose' '
>> +       git -c commit.verbose=true commit --amend --no-verbose &&
>> +       ! test -s out
>> +'
>> +
>> +test_expect_success 'commit.verbose false and --verbose' '
>> +       git -c commit.verbose=false commit --amend --verbose &&
>> +       test_line_count = 1 out
>> +'
>> +
>> +test_expect_success 'commit.verbose false and -v -v' '
>> +       git -c commit.verbose=false commit --amend -v -v &&
>> +       test_line_count = 2 out
>> +'
>> +
>> +test_expect_success 'commit.verbose false and --verbose omitted' '
>> +       git -c commit.verbose=false commit --amend &&
>> +       ! test -s out
>> +'
>> +
>> +test_expect_success 'commit.verbose false and --no-verbose' '
>> +       git -c commit.verbose=false commit --amend --no-verbose &&
>> +       ! test -s out
>> +'
>> +
>> +test_expect_success 'status ignores commit.verbose=true' '
>> +       git -c commit.verbose=true status >actual &&
>> +       ! grep "^diff --git" actual
>> +'
>
> The fact that v9 broke a number of tests in other scripts which use
> git-status (as SZEDER pointed out[1]), due to initializing 'verbose'
> to -1 in builtin/commit.c, suggests that you probably ought to add
> another test here to protect against that sort of breakage, as well.
> Specifically, git-status should remain non-verbose when neither
> commit.verbose nor --verbose is specified.

Yes, I should. I will include that.
>> +
>>  test_done

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Eric Sunshine]

On Sun, Mar 27, 2016 at 3:00 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Sun, Mar 27, 2016 at 9:04 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> +test_expect_success 'commit.verbose true and --verbose omitted' '
>>> +       echo content >file2 &&
>>> +       echo content >>file &&
>>> +       git add file2 &&
>>> +       git -c commit.verbose=true commit -F message &&
>>> +       test_line_count = 1 out
>>> +'
>>
>> Why is this test so utterly different than it was in v9 (even though
>> the title is the same), and why is it so different from other tests
>> below?
>
> This is because the "editor" in v9 checked for "# Changes"... While
> this "editor" checks for 'diff --git'. And submodules don't give a
> proper diff to verify (I tried this out and noticed this behavior by
> tweaking some parts). In fact submodules don't give diff at all. But
> they do give "# Changes"... So its important to setup up a little
> before getting started. If this seems unnecessary, then should I move
> all the tests which were introduced here above the submodule test?

Let's ignore submodules when discussing this since they don't need to
factor into the issue. What you are actually saying (and what took me
a while to understand due to the "submodules" misdirection) is that
you need to do some additional setup to test the "-v -v" cases. In
particular, you need to introduce some change to the worktree which is
not in the index.

The typical way to satisfy this requirement (which doesn't require
relocating tests) is to add a "setup" test before the tests which
depend upon that additional setup, rather than adding that setup to
the first test which needs it. Just about the simplest setup test
which satisfies your needs is the following (inserted just before the
first of the new tests):

    test_expect_success 'setup -v -v' '
        echo dirty >file
    '

And, then you can restore the "commit.verbose true and --verbose
omitted" test to its simple form:

    test_expect_success 'commit.verbose true and --verbose omitted' '
        git -c commit.verbose=true commit --amend &&
        test_line_count = 1 out
    '


By the way, now that commit.verbose is no longer a mere boolean,
you're going to need some additional tests beyond the
commit.verbose={true,false} ones you've already added. In particular,
you should be testing commit.verbose with several numeric values to
verify that it works as expected. For instance:

    commit.verbose=-2
    commit.verbose=-1
    commit.verbose=0
    commit.verbose=1
    commit.verbose=2
    commit.verbose=3

The -2 case is interesting; I'm pretty sure the current implementation
of this patch will misbehave since the only negative value it's

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

On Sun, Mar 27, 2016 at 1:47 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sun, Mar 27, 2016 at 3:00 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Sun, Mar 27, 2016 at 9:04 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>>> +test_expect_success 'commit.verbose true and --verbose omitted' '
>>>> +       echo content >file2 &&
>>>> +       echo content >>file &&
>>>> +       git add file2 &&
>>>> +       git -c commit.verbose=true commit -F message &&
>>>> +       test_line_count = 1 out
>>>> +'
>>>
>>> Why is this test so utterly different than it was in v9 (even though
>>> the title is the same), and why is it so different from other tests
>>> below?
>>
>> This is because the "editor" in v9 checked for "# Changes"... While
>> this "editor" checks for 'diff --git'. And submodules don't give a
>> proper diff to verify (I tried this out and noticed this behavior by
>> tweaking some parts). In fact submodules don't give diff at all. But
>> they do give "# Changes"... So its important to setup up a little
>> before getting started. If this seems unnecessary, then should I move
>> all the tests which were introduced here above the submodule test?
>
> Let's ignore submodules when discussing this since they don't need to
> factor into the issue. What you are actually saying (and what took me
> a while to understand due to the "submodules" misdirection) is that
> you need to do some additional setup to test the "-v -v" cases. In
> particular, you need to introduce some change to the worktree which is
> not in the index.

Sorry for the misdirection. And you understood correctly. I do need to
introduce some changes in worktree.

> The typical way to satisfy this requirement (which doesn't require
> relocating tests) is to add a "setup" test before the tests which
> depend upon that additional setup, rather than adding that setup to
> the first test which needs it. Just about the simplest setup test
> which satisfies your needs is the following (inserted just before the
> first of the new tests):
>
>     test_expect_success 'setup -v -v' '
>         echo dirty >file
>     '
>
> And, then you can restore the "commit.verbose true and --verbose
> omitted" test to its simple form:
>
>     test_expect_success 'commit.verbose true and --verbose omitted' '
>         git -c commit.verbose=true commit --amend &&
>         test_line_count = 1 out
>     '

Having a additional setup test seems a nice way to go about.


> By the way, now that commit.verbose is no longer a mere boolean,
> you're going to need some additional tests beyond the
> commit.verbose={true,false} ones you've already added. In particular,
> you should be testing commit.verbose with several numeric values to
> verify that it works as expected. For instance:
>
>     commit.verbose=-2
>     commit.verbose=-1
>     commit.verbose=0
>     commit.verbose=1
>     commit.verbose=2
>     commit.verbose=3
>
> The -2 case is interesting; I'm pretty sure the current implementation
> of this patch will misbehave since the only negative value it's
> expecting 'config_verbose' to be is -1.

-2 case will fail. I should probably expect 'config_verbose' to be
negative instead.

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[SZEDER Gábor]

> +test_expect_success 'commit.verbose true and --no-verbose' '
> +	git -c commit.verbose=true commit --amend --no-verbose &&
> +	! test -s out

Please use the test_must_be_empty helper instead, because it has a
nice, human-readable name and it complains with a helpful error
message if something goes wrong, whereas 'test -s' just fails
silently.

> +'
> +
> +test_expect_success 'commit.verbose false and --verbose' '
> +	git -c commit.verbose=false commit --amend --verbose &&
> +	test_line_count = 1 out
> +'
> +
> +test_expect_success 'commit.verbose false and -v -v' '
> +	git -c commit.verbose=false commit --amend -v -v &&
> +	test_line_count = 2 out
> +'
> +
> +test_expect_success 'commit.verbose false and --verbose omitted' '
> +	git -c commit.verbose=false commit --amend &&
> +	! test -s out
> +'
> +
> +test_expect_success 'commit.verbose false and --no-verbose' '
> +	git -c commit.verbose=false commit --amend --no-verbose &&
> +	! test -s out
> +'
> +
> +test_expect_success 'status ignores commit.verbose=true' '
> +	git -c commit.verbose=true status >actual &&
> +	! grep "^diff --git" actual
> +'
> +
>  test_done
> 
> --
> https://github.com/git/git/pull/218
> 
> 

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

On Sun, Mar 27, 2016 at 5:21 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> +test_expect_success 'commit.verbose true and --no-verbose' '
>> +     git -c commit.verbose=true commit --amend --no-verbose &&
>> +     ! test -s out
>
> Please use the test_must_be_empty helper instead, because it has a
> nice, human-readable name and it complains with a helpful error
> message if something goes wrong, whereas 'test -s' just fails
> silently.

Thanks for pointing it out. I was unsure whether 'test -s' is a good
choice but used it since I did not know any other alternative.

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[SZEDER Gábor]

Quoting Pranit Bauva <pranit.bauva@gmail.com>:

> On Sun, Mar 27, 2016 at 5:21 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>> +test_expect_success 'commit.verbose true and --no-verbose' '
>>> +     git -c commit.verbose=true commit --amend --no-verbose &&
>>> +     ! test -s out
>>
>> Please use the test_must_be_empty helper instead, because it has a
>> nice, human-readable name and it complains with a helpful error
>> message if something goes wrong, whereas 'test -s' just fails
>> silently.
>
> Thanks for pointing it out. I was unsure whether 'test -s' is a good
> choice but used it since I did not know any other alternative.

t/test-lib-functions.sh contains all our test helpers functions, that's
where you can look for a suitable helper, should it be necessary.

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Pranit Bauva]

On Sun, Mar 27, 2016 at 5:37 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> t/test-lib-functions.sh contains all our test helpers functions, that's
> where you can look for a suitable helper, should it be necessary.
Thanks. I will surely look into it.

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[SZEDER Gábor]

> > +! test -s out ||
> > +rm out &&
> 
> Why not just "rm -f out"? But, more importantly, why do you need to
> remove the file at all? The '>' redirection operator (used below) will
> overwrite the file, so no need to remove it beforehand.
> 
> > +! grep '^diff --git' "$1" ||
> > +grep '^diff --git' "$1" >out
> 
> Um, what? Why two greps? I would have expected you to simply re-use
> the existing grep (minus the backslash) while adding the redirection:
> 
>     -exec grep '^diff --git' "\$1"
>     +exec grep '^diff --git' "$1" >out
> 
> Am I missing something obvious?

In the non-verbose cases no diff is included in the commit message
template, thus the pattern looking for it doesn't match anything, grep
exits with error code, which in turn becomes the editor's exit
code, ultimately making 'git commit' fail.  Not good.

I suppose both the explicit 'rm out' and the '! grep ... || ...' is
there to deal with this situation.

Hmph.

I think we could:

  - either revive the idea of two editor scripts: one for the
    non-verbose case checking with '! grep ...' that there are no
    diffs in the commit message template, and one for all verbose
    cases storing those diff lines in a file to be counted later.

  - or use a fake editor that merely copies the whole commit message
    template to a separate file, and we do the greping in the tests
    themselves as well.

  - or simply stick a 'true' at the end of the editor script ensuring
    that it returns success even when grep can't find the pattern, but
    I kind of feel ashamed of myself for even mentioning this
    possibility ;)

I would go for the second possibility, but don't feel strong about it.

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Pranit Bauva]

On Sun, Mar 27, 2016 at 6:57 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>> > +! test -s out ||
>> > +rm out &&
>>
>> Why not just "rm -f out"? But, more importantly, why do you need to
>> remove the file at all? The '>' redirection operator (used below) will
>> overwrite the file, so no need to remove it beforehand.
>>
>> > +! grep '^diff --git' "$1" ||
>> > +grep '^diff --git' "$1" >out
>>
>> Um, what? Why two greps? I would have expected you to simply re-use
>> the existing grep (minus the backslash) while adding the redirection:
>>
>>     -exec grep '^diff --git' "\$1"
>>     +exec grep '^diff --git' "$1" >out
>>
>> Am I missing something obvious?
>
> In the non-verbose cases no diff is included in the commit message
> template, thus the pattern looking for it doesn't match anything, grep
> exits with error code, which in turn becomes the editor's exit
> code, ultimately making 'git commit' fail.  Not good.
>
> I suppose both the explicit 'rm out' and the '! grep ... || ...' is
> there to deal with this situation.

Yes. In fact, I did this as a last resort after trying a lot of other
stuff which didn't work.

> Hmph.
>
> I think we could:
>
>   - either revive the idea of two editor scripts: one for the
>     non-verbose case checking with '! grep ...' that there are no
>     diffs in the commit message template, and one for all verbose
>     cases storing those diff lines in a file to be counted later.
>
>   - or use a fake editor that merely copies the whole commit message
>     template to a separate file, and we do the greping in the tests
>     themselves as well.
>
>   - or simply stick a 'true' at the end of the editor script ensuring
>     that it returns success even when grep can't find the pattern, but
>     I kind of feel ashamed of myself for even mentioning this
>     possibility ;)
>
> I would go for the second possibility, but don't feel strong about it.

There is one more possibility, that we could use 'test_must_fail' (as
grep exits with error code with no diff) but this will send a very
wrong interpretation as "This type of scenario is not meant to work".
Or to put it in better words, "You cannot have no diff with commit".
There is a difference between two negatives and one positive.

Re: [PATCH v10 3/3] commit: add a commit.verbose config variable

[Eric Sunshine]

On Sun, Mar 27, 2016 at 7:59 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Sun, Mar 27, 2016 at 5:21 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:
>>> +test_expect_success 'commit.verbose true and --no-verbose' '
>>> +     git -c commit.verbose=true commit --amend --no-verbose &&
>>> +     ! test -s out
>>
>> Please use the test_must_be_empty helper instead, because it has a
>> nice, human-readable name and it complains with a helpful error
>> message if something goes wrong, whereas 'test -s' just fails
>> silently.
>
> Thanks for pointing it out. I was unsure whether 'test -s' is a good
> choice but used it since I did not know any other alternative.

For these particular tests, it would be more stylized to use:

    test_line_count = 0 out

which would keep them consistent with other tests in the same file which use:

    test_line_count = 1 out
    ...
    test_line_count = 2 out

however, that's a minor point.

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Eric Sunshine]

[forwarding this to the list since Pranit (presumably) accidentally
replied only to me but it's relevant to the ongoing discussion]

On Sun, Mar 27, 2016 at 1:42 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Sun, Mar 27, 2016 at 8:37 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> So that we can see how many diffs were contained in the message and use
>>> them in individual tests where ever it is required. Also use
>>> write_script() to create the fake "editor".
>>
>> It is important to explain *why* you want to be able to count how many
>> diffs were in the editor message. In particular, you will be adding
>> new tests in a subsequent patch which will expect a specific number of
>> diffs (rather than any number of diffs)
>>
>> Also, you need to explain why you're changing the existing tests to
>> count the number of diffs. Is it simply "because you can" or is it
>> because you suspect that a change you're making in a subsequent patch
>> might accidentally cause too many diffs to show up in the existing
>> test cases?
>
> Sorry for not writing commit messages properly. It is a part I am working on.
> How does this paragraph sound to you in addition to the previous commit message?
> "A subsequent commit will introduce a scenario where it is important
> to be able to exactly determine how many diffs were present."
>
>>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>>> ---
>>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>>> @@ -3,9 +3,11 @@
>>> -cat >check-for-diff <<EOF
>>> -#!$SHELL_PATH
>>> -exec grep '^diff --git' "\$1"
>>> +write_script "check-for-diff" <<'EOF' &&
>>
>> The 'EOF' is more commonly written as \EOF in Git test scripts.
>>
>>> +! test -s out ||
>>> +rm out &&
>>
>> Why not just "rm -f out"? But, more importantly, why do you need to
>> remove the file at all? The '>' redirection operator (used below) will
>> overwrite the file, so no need to remove it beforehand.
>
> I wasn't aware about '-f' option. It is important to remove the file.
> I initially tried without removing the file and it caused problems.
> This is because let's say the previous test had 1 diff which was
> stored in out. Now, if in the next test, it is expected to have 0
> diffs then grep would fail to execute and nothing will be re-written
> to out and out will contain the 1 diff from previous test. An
> explanation for this should be mentioned in the commit message?
>
>>> +! grep '^diff --git' "$1" ||
>>> +grep '^diff --git' "$1" >out
>>
>> Um, what? Why two greps? I would have expected you to simply re-use
>> the existing grep (minus the backslash) while adding the redirection:
>>
>>     -exec grep '^diff --git' "\$1"
>>     +exec grep '^diff --git' "$1" >out
>
> The reason of two greps in that if in some test it fails to find any
> diffs, the editor will return an error. Of course we could test this
> scenario by using test_must_fail as in previous patches, but I think
> it would be more clearer if we could test for the existence of out
> which is done in patch 3/3. I will explanation for this in commit
> message.
>
>>>  EOF
>>>  chmod +x check-for-diff
>>
>> Mentioned previously[1]: Drop the 'chmod' since write_script() does it for you.
>>
>> [1]: http://article.gmane.org/gmane.comp.version-control.git/289832
>
> Then you mentioned that you were talking[1] about some other review.
> So I thought you mean to keep as it is. I guess I misinterpreted it.
> And I did not test that before. Now, I have tested that it works if we
> remove chmod.
> [1] : http://thread.gmane.org/gmane.comp.version-control.git/288820/focus=289832
>
>>>  test_set_editor "$PWD/check-for-diff"
>>> @@ -23,7 +25,8 @@ test_expect_success 'setup' '
>>>  test_expect_success 'initial commit shows verbose diff' '
>>> -       git commit --amend -v
>>> +       git commit --amend -v &&
>>> +       test_line_count = 1 out
>>>  '
>>>
>>>  test_expect_success 'second commit' '
>>> @@ -39,13 +42,15 @@ check_message() {
>>>
>>>  test_expect_success 'verbose diff is stripped out' '
>>>         git commit --amend -v &&
>>> -       check_message message
>>> +       check_message message &&
>>> +       test_line_count = 1 out
>>>  '
>>>
>>>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
>>>         git config diff.mnemonicprefix true &&
>>>         git commit --amend -v &&
>>> -       check_message message
>>> +       check_message message &&
>>> +       test_line_count = 1 out
>>>  '

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Eric Sunshine]

[also forwarding this to the list since it's relevant to the ongoing
discussion, and I hadn't noticed when replying that Pranit had
(presumably) accidentally dropped the git list as a recipient]

On Sun, Mar 27, 2016 at 3:10 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sun, Mar 27, 2016 at 1:42 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Sun, Mar 27, 2016 at 8:37 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Sat, Mar 26, 2016 at 3:48 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> It is important to explain *why* you want to be able to count how many
>>> diffs were in the editor message. In particular, you will be adding
>>> new tests in a subsequent patch which will expect a specific number of
>>> diffs (rather than any number of diffs)
>>>
>>> Also, you need to explain why you're changing the existing tests to
>>> count the number of diffs. Is it simply "because you can" or is it
>>> because you suspect that a change you're making in a subsequent patch
>>> might accidentally cause too many diffs to show up in the existing
>>> test cases?
>>
>> Sorry for not writing commit messages properly. It is a part I am working on.
>> How does this paragraph sound to you in addition to the previous commit message?
>> "A subsequent commit will introduce a scenario where it is important
>> to be able to exactly determine how many diffs were present."
>
> That's fine for explaining why 'check-for-diff' is being updated to
> store the output, but you still need to explain why you're changing
> the existing tests.
>
>>>> -cat >check-for-diff <<EOF
>>>> -#!$SHELL_PATH
>>>> -exec grep '^diff --git' "\$1"
>>>> +write_script "check-for-diff" <<'EOF' &&
>>>> +! test -s out ||
>>>> +rm out &&
>>>
>>> Why not just "rm -f out"? But, more importantly, why do you need to
>>> remove the file at all? The '>' redirection operator (used below) will
>>> overwrite the file, so no need to remove it beforehand.
>>
>> I wasn't aware about '-f' option. It is important to remove the file.
>> I initially tried without removing the file and it caused problems.
>> This is because let's say the previous test had 1 diff which was
>> stored in out. Now, if in the next test, it is expected to have 0
>> diffs then grep would fail to execute and nothing will be re-written
>> to out and out will contain the 1 diff from previous test. An
>> explanation for this should be mentioned in the commit message?
>
> No. Rather than trying to explain all this in the commit message, it
> would be better to retain a simple implementation of 'check-for-diff'
> rather than adding several levels of complication. More about this
> below...
>
>>>> +! grep '^diff --git' "$1" ||
>>>> +grep '^diff --git' "$1" >out
>>>
>>> Um, what? Why two greps? I would have expected you to simply re-use
>>> the existing grep (minus the backslash) while adding the redirection:
>>>
>>>     -exec grep '^diff --git' "\$1"
>>>     +exec grep '^diff --git' "$1" >out
>>
>> The reason of two greps in that if in some test it fails to find any
>> diffs, the editor will return an error. Of course we could test this
>> scenario by using test_must_fail as in previous patches, but I think
>> it would be more clearer if we could test for the existence of out
>> which is done in patch 3/3. I will explanation for this in commit
>> message.
>
> This sounds unnecessarily complicated. It's not too difficult to
> reason about a script named 'check-for-diff' actually "checking for
> presence of diffs" and failing if no diff is present, from which it
> follows naturally that new tests which don't expect any diffs would
> use test_must_fail. Keeping it simple like this also makes this patch
> much less noisy since it doesn't require changing existing tests.
>
> Likewise, it keeps most of the new tests in 3/3 small because the bulk
> of them only want to know that a diff was present, but don't care
> about the number of diffs. However, it's not necessarily a bad thing
> to ensure that you got the number of diffs you expected (for instance,
> that a single -v really behaved as -v, and not as -v -v), so that can
> be used as an argument for overhauling the old tests, as well as using
> counting in all new tests.
>
> However, even if you take the approach of making 'check-for-diff'
> succeed unconditionally and always count diffs, the current
> implementation is still overly complicated. It would be much simpler
> to let 'check-for-diff' always create the output file, and then use
> "test_line_count = 0 out" when expecting no diffs than to sometimes
> create the output file and sometimes not. The shell '>' operator will
> truncate the file to zero size even before grep is invoked, so you
> don't need to worry that results from an earlier test will pollute
> 'out' for a subsequent test, even if grep finds no matches. Thus,
> 'check-for-diff' collapses to this tiny implementation:
>
>     grep '^diff --git' "$1" >out
>     exit 0
>
> Or, if you want to be terse:
>
>     grep '^diff --git' "$1" || exit 0 >out
>
> A couple notes: First, "out" isn't a great name for this file; perhaps
> come up with a better name. Second, under this scenario,
> "check-for-diff" isn't the most accurate name; it's now simply
> collecting diffs rather than checking for presence.
>
> An alternative would be for the output file to contain the actual
> count of diffs, rather than the diff lines themselves. For instance:
>
>     write_script count-diffs <<\EOF &&
>     grep -c '^diff --git' "$1" >out
>     exit 0
>     EOF
>
> Whether that's actually better is subjective.
>
> So, what's my final word? I quite like the idea of keeping everything
> as simple as possible, thus not altering existing tests and only doing
> line count in the two or three new tests which actually care about the
> number of diffs. However, I can also be sold on retrofitting existing
> tests and having new tests do line counting as a way to improve test
> coverage by catching cases where "-v" incorrectly behaves as "-v -v".
> If you go that route, then the commit message of this patch needs to
> sell it as such (an improvement in test coverage).

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Eric Sunshine]

[forwarding this to the list, as well, since I again didn't notice
when replying that Pranit had accidentally dropped the mailing list as
a recipient]

On Sun, Mar 27, 2016 at 12:59 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sun, Mar 27, 2016 at 5:05 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Sun, Mar 27, 2016 at 12:40 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> However, even if you take the approach of making 'check-for-diff'
>>> succeed unconditionally and always count diffs, the current
>>> implementation is still overly complicated. It would be much simpler
>>> to let 'check-for-diff' always create the output file, and then use
>>> "test_line_count = 0 out" when expecting no diffs than to sometimes
>>> create the output file and sometimes not. The shell '>' operator will
>>> truncate the file to zero size even before grep is invoked, so you
>>> don't need to worry that results from an earlier test will pollute
>>> 'out' for a subsequent test, even if grep finds no matches. Thus,
>>> 'check-for-diff' collapses to this tiny implementation:
>>>
>>>     grep '^diff --git' "$1" >out
>>>     exit 0
>>>
>>> Or, if you want to be terse:
>>>
>>>     grep '^diff --git' "$1" || exit 0 >out
>>
>> I tried using both of this and it gives an error
>
> These worked fine for me when I rewrote the test script before making
> the suggestion. You'll need to provide more information if you want to
> get to the bottom of the problem you experienced (for instance, show
> the exact code you used and the actual error message).

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Eric Sunshine]

On Sun, Mar 27, 2016 at 03:27:25PM +0200, SZEDER Gábor wrote:
> > > +! test -s out ||
> > > +rm out &&
> > 
> > Why not just "rm -f out"? But, more importantly, why do you need to
> > remove the file at all? The '>' redirection operator (used below) will
> > overwrite the file, so no need to remove it beforehand.
> > 
> > > +! grep '^diff --git' "$1" ||
> > > +grep '^diff --git' "$1" >out
> > 
> > Um, what? Why two greps? I would have expected you to simply re-use
> > the existing grep (minus the backslash) while adding the redirection:
> > 
> >     -exec grep '^diff --git' "\$1"
> >     +exec grep '^diff --git' "$1" >out
> > 
> > Am I missing something obvious?
> 
> In the non-verbose cases no diff is included in the commit message
> template, thus the pattern looking for it doesn't match anything, grep
> exits with error code, which in turn becomes the editor's exit
> code, ultimately making 'git commit' fail.  Not good.
> 
> I suppose both the explicit 'rm out' and the '! grep ... || ...' is
> there to deal with this situation.

Sure, I understand that, but that's not what I meant. What I wanted
to know was why Pranit didn't just use the simpler:

    grep '^diff --git' "$1" >out
    exit 0

and then, in tests:

    test_line_count = n out

where 'n' is 0, 1, or 2 as expected by the test.

Unfortunately, you missed the rest of the discussion since Pranit
(presumably) accidentally dropped the mailing list when he replied,
and I didn't notice the omission when replying to him with the above
suggestion, which would have saved you the bother of going through
this, as well.

> I think we could:
> 
>   - either revive the idea of two editor scripts: one for the
>     non-verbose case checking with '! grep ...' that there are no
>     diffs in the commit message template, and one for all verbose
>     cases storing those diff lines in a file to be counted later.
> 
>   - or use a fake editor that merely copies the whole commit message
>     template to a separate file, and we do the greping in the tests
>     themselves as well.
> 
>   - or simply stick a 'true' at the end of the editor script ensuring
>     that it returns success even when grep can't find the pattern, but
>     I kind of feel ashamed of myself for even mentioning this
>     possibility ;)
> 
> I would go for the second possibility, but don't feel strong about it.

Your #3 is effectively what I had suggested, as well (which is
reproduced above). I had already made this change locally along with
some other changes I suggested in other responses, and those changes
look like this (atop Pranit's two patches), which isn't too bad:

--- 8< ---
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 569fd8b..ea26b57 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -4,12 +4,9 @@ test_description='verbose commit template'
 . ./test-lib.sh
 
 write_script "check-for-diff" <<'EOF' &&
-! test -s out ||
-rm out &&
-! grep '^diff --git' "$1" ||
 grep '^diff --git' "$1" >out
+exit 0
 EOF
-chmod +x check-for-diff
 test_set_editor "$PWD/check-for-diff"
 
 cat >message <<'EOF'
@@ -101,11 +98,12 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'setup -v -v' '
+	echo dirty >file
+'
+
 test_expect_success 'commit.verbose true and --verbose omitted' '
-	echo content >file2 &&
-	echo content >>file &&
-	git add file2 &&
-	git -c commit.verbose=true commit -F message &&
+	git -c commit.verbose=true commit --amend &&
 	test_line_count = 1 out
 '
 
@@ -121,7 +119,7 @@ test_expect_success 'commit.verbose true and -v -v' '
 
 test_expect_success 'commit.verbose true and --no-verbose' '
 	git -c commit.verbose=true commit --amend --no-verbose &&
-	! test -s out
+	test_line_count = 0 out
 '
 
 test_expect_success 'commit.verbose false and --verbose' '
@@ -136,12 +134,12 @@ test_expect_success 'commit.verbose false and -v -v' '
 
 test_expect_success 'commit.verbose false and --verbose omitted' '
 	git -c commit.verbose=false commit --amend &&
-	! test -s out
+	test_line_count = 0 out
 '
 
 test_expect_success 'commit.verbose false and --no-verbose' '
 	git -c commit.verbose=false commit --amend --no-verbose &&
-	! test -s out
+	test_line_count = 0 out
 '
 
 test_expect_success 'status ignores commit.verbose=true' '
-- 

Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file

[Pranit Bauva]

On Sun, Mar 27, 2016 at 10:57 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sun, Mar 27, 2016 at 03:27:25PM +0200, SZEDER Gábor wrote:
>> > > +! test -s out ||
>> > > +rm out &&
>> >
>> > Why not just "rm -f out"? But, more importantly, why do you need to
>> > remove the file at all? The '>' redirection operator (used below) will
>> > overwrite the file, so no need to remove it beforehand.
>> >
>> > > +! grep '^diff --git' "$1" ||
>> > > +grep '^diff --git' "$1" >out
>> >
>> > Um, what? Why two greps? I would have expected you to simply re-use
>> > the existing grep (minus the backslash) while adding the redirection:
>> >
>> >     -exec grep '^diff --git' "\$1"
>> >     +exec grep '^diff --git' "$1" >out
>> >
>> > Am I missing something obvious?
>>
>> In the non-verbose cases no diff is included in the commit message
>> template, thus the pattern looking for it doesn't match anything, grep
>> exits with error code, which in turn becomes the editor's exit
>> code, ultimately making 'git commit' fail.  Not good.
>>
>> I suppose both the explicit 'rm out' and the '! grep ... || ...' is
>> there to deal with this situation.
>
> Sure, I understand that, but that's not what I meant. What I wanted
> to know was why Pranit didn't just use the simpler:
>
>     grep '^diff --git' "$1" >out
>     exit 0
>
> and then, in tests:
>
>     test_line_count = n out
>
> where 'n' is 0, 1, or 2 as expected by the test.

Sorry to create extra noise. This works perfectly fine. I had put an
'exec' locally. But now I have tested this and it works fine..

>
> Unfortunately, you missed the rest of the discussion since Pranit
> (presumably) accidentally dropped the mailing list when he replied,
> and I didn't notice the omission when replying to him with the above
> suggestion, which would have saved you the bother of going through
> this, as well.

Sorry for this. I might have just started typing and forgot to click reply all.
>> I think we could:
>>
>>   - either revive the idea of two editor scripts: one for the
>>     non-verbose case checking with '! grep ...' that there are no
>>     diffs in the commit message template, and one for all verbose
>>     cases storing those diff lines in a file to be counted later.
>>
>>   - or use a fake editor that merely copies the whole commit message
>>     template to a separate file, and we do the greping in the tests
>>     themselves as well.
>>
>>   - or simply stick a 'true' at the end of the editor script ensuring
>>     that it returns success even when grep can't find the pattern, but
>>     I kind of feel ashamed of myself for even mentioning this
>>     possibility ;)
>>
>> I would go for the second possibility, but don't feel strong about it.
>
> Your #3 is effectively what I had suggested, as well (which is
> reproduced above). I had already made this change locally along with
> some other changes I suggested in other responses, and those changes
> look like this (atop Pranit's two patches), which isn't too bad:
>
> --- 8< ---
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> index 569fd8b..ea26b57 100755
> --- a/t/t7507-commit-verbose.sh
> +++ b/t/t7507-commit-verbose.sh
> @@ -4,12 +4,9 @@ test_description='verbose commit template'
>  . ./test-lib.sh
>
>  write_script "check-for-diff" <<'EOF' &&
> -! test -s out ||
> -rm out &&
> -! grep '^diff --git' "$1" ||
>  grep '^diff --git' "$1" >out
> +exit 0
>  EOF
> -chmod +x check-for-diff
>  test_set_editor "$PWD/check-for-diff"
>
>  cat >message <<'EOF'
> @@ -101,11 +98,12 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
>         test_i18ngrep "Aborting commit due to empty commit message." err
>  '
>
> +test_expect_success 'setup -v -v' '
> +       echo dirty >file
> +'
> +
>  test_expect_success 'commit.verbose true and --verbose omitted' '
> -       echo content >file2 &&
> -       echo content >>file &&
> -       git add file2 &&
> -       git -c commit.verbose=true commit -F message &&
> +       git -c commit.verbose=true commit --amend &&
>         test_line_count = 1 out
>  '
>
> @@ -121,7 +119,7 @@ test_expect_success 'commit.verbose true and -v -v' '
>
>  test_expect_success 'commit.verbose true and --no-verbose' '
>         git -c commit.verbose=true commit --amend --no-verbose &&
> -       ! test -s out
> +       test_line_count = 0 out
>  '
>
>  test_expect_success 'commit.verbose false and --verbose' '
> @@ -136,12 +134,12 @@ test_expect_success 'commit.verbose false and -v -v' '
>
>  test_expect_success 'commit.verbose false and --verbose omitted' '
>         git -c commit.verbose=false commit --amend &&
> -       ! test -s out
> +       test_line_count = 0 out
>  '
>
>  test_expect_success 'commit.verbose false and --no-verbose' '
>         git -c commit.verbose=false commit --amend --no-verbose &&
> -       ! test -s out
> +       test_line_count = 0 out
>  '
>
>  test_expect_success 'status ignores commit.verbose=true' '
> --

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

[Pranit Bauva]

> A couple of new tests to t0040-parse-options.sh would be great to
> ensure that starting from a negative value works as advertised, i.e.
> at least that '--option' jumps to 1 and '--no-option' resets to 0.

I think adding tests to t0040-parse-options.sh cannot reflect the
behavior introduced by this patch.
This is because setting the initial value of the variable (which is
going to be modified by the argument) is set in test-parse-options.c .
A possible solution will be to modify the test-parse-options.c and
initialize the required variable (verbose or quiet) to "unspecified"
value. But then this will leave one part of the untested ie. when the
initial value of the variable is 0. I could do one thing to test these
both behaviors which is to set verbose initially to -1 and leave quiet
= 0. Since verbose and quiet are both consumers of OPT_COUNTUP, this
can test both the behaviors.

I tried searching for alternatives but could not find any. Is there
something else which you had thought before that would test this
behavior?

If not, then we are left with 2 options, either modify
test-parse-options.c or just hand test it whenever there seems to be a
problematic case.

Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values

[Eric Sunshine]

On Mon, Mar 28, 2016 at 2:42 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> A couple of new tests to t0040-parse-options.sh would be great to
>> ensure that starting from a negative value works as advertised, i.e.
>> at least that '--option' jumps to 1 and '--no-option' resets to 0.
>
> I think adding tests to t0040-parse-options.sh cannot reflect the
> behavior introduced by this patch.
> This is because setting the initial value of the variable (which is
> going to be modified by the argument) is set in test-parse-options.c .
> A possible solution will be to modify the test-parse-options.c and
> initialize the required variable (verbose or quiet) to "unspecified"
> value. But then this will leave one part of the untested ie. when the
> initial value of the variable is 0. I could do one thing to test these
> both behaviors which is to set verbose initially to -1 and leave quiet
> = 0. Since verbose and quiet are both consumers of OPT_COUNTUP, this
> can test both the behaviors.
>
> I tried searching for alternatives but could not find any. Is there
> something else which you had thought before that would test this
> behavior?
>
> If not, then we are left with 2 options, either modify
> test-parse-options.c or just hand test it whenever there seems to be a
> problematic case.

Modifying test-parse-options.c, if needed, was implied by SZEDER's
suggestion to add tests for this new behavior. test-parse-options.c
exists strictly for testing option parsing, so don't feel constrained
about modifying or extending it in order to test the new count-up
behavior if the existing implementation doesn't directly support what
you want it to do.

[PATCH v11 1/4] test-parse-options: print quiet as integer

[Pranit Bauva]

Current implementation of parse-options.c treats OPT__QUIET() as integer
and not boolean and thus it is more appropriate to print it as integer
to avoid confusion.

While at it, fix some style issues.
---
 t/t0040-parse-options.sh | 94 ++++++++++++++++++++++++------------------------
 test-parse-options.c     |  2 +-
 2 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 9be6411..2dcbdc0 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -7,7 +7,7 @@ test_description='our own option parser'
 
 . ./test-lib.sh
 
-cat > expect << EOF
+cat >expect <<EOF
 usage: test-parse-options <options>
 
     --yes                 get a boolean
@@ -49,7 +49,7 @@ Standard options
 EOF
 
 test_expect_success 'test help' '
-	test_must_fail test-parse-options -h > output 2> output.err &&
+	test_must_fail test-parse-options -h >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_i18ncmp expect output
 '
@@ -64,7 +64,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -156,7 +156,7 @@ test_expect_success 'OPT_MAGNITUDE() 3giga' '
 	check magnitude: 3221225472 -m 3g
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -164,7 +164,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 2
-quiet: no
+quiet: 0
 dry run: yes
 file: prefix/my.file
 EOF
@@ -176,7 +176,7 @@ test_expect_success 'short options' '
 	test_must_be_empty output.err
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -184,7 +184,7 @@ timestamp: 0
 string: 321
 abbrev: 10
 verbose: 2
-quiet: no
+quiet: 0
 dry run: no
 file: prefix/fi.le
 EOF
@@ -204,7 +204,7 @@ test_expect_success 'missing required value' '
 	test_expect_code 129 test-parse-options --file
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 1
 integer: 13
 magnitude: 0
@@ -212,7 +212,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: a1
@@ -222,12 +222,12 @@ EOF
 
 test_expect_success 'intermingled arguments' '
 	test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
-		> output 2> output.err &&
+		>output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 0
 integer: 2
 magnitude: 0
@@ -235,19 +235,19 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
 
 test_expect_success 'unambiguously abbreviated option' '
-	test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
+	test-parse-options --int 2 --boolean --no-bo >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'unambiguously abbreviated option with "="' '
-	test-parse-options --int=2 > output 2> output.err &&
+	test-parse-options --int=2 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
@@ -256,7 +256,7 @@ test_expect_success 'ambiguously abbreviated option' '
 	test_expect_code 129 test-parse-options --strin 123
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -264,38 +264,38 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
 
 test_expect_success 'non ambiguous option (after two options it abbreviates)' '
-	test-parse-options --st 123 > output 2> output.err &&
+	test-parse-options --st 123 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > typo.err << EOF
+cat >typo.err <<EOF
 error: did you mean \`--boolean\` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -boolean > output 2> output.err &&
+	test_must_fail test-parse-options -boolean >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > typo.err << EOF
+cat >typo.err <<EOF
 error: did you mean \`--ambiguous\` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -ambiguous > output 2> output.err &&
+	test_must_fail test-parse-options -ambiguous >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -303,19 +303,19 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: --quux
 EOF
 
 test_expect_success 'keep some options as arguments' '
-	test-parse-options --quux > output 2> output.err &&
+	test-parse-options --quux >output 2>output.err &&
 	test_must_be_empty output.err &&
-        test_cmp expect output
+	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -323,7 +323,7 @@ timestamp: 1
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: yes
+quiet: 1
 dry run: no
 file: (not set)
 arg 00: foo
@@ -331,12 +331,12 @@ EOF
 
 test_expect_success 'OPT_DATE() works' '
 	test-parse-options -t "1970-01-01 00:00:01 +0000" \
-		foo -q > output 2> output.err &&
+		foo -q >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 Callback: "four", 0
 boolean: 5
 integer: 4
@@ -345,28 +345,28 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
 
 test_expect_success 'OPT_CALLBACK() and OPT_BIT() work' '
-	test-parse-options --length=four -b -4 > output 2> output.err &&
+	test-parse-options --length=four -b -4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 Callback: "not set", 1
 EOF
 
 test_expect_success 'OPT_CALLBACK() and callback errors work' '
-	test_must_fail test-parse-options --no-length > output 2> output.err &&
+	test_must_fail test-parse-options --no-length >output 2>output.err &&
 	test_i18ncmp expect output &&
 	test_i18ncmp expect.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 1
 integer: 23
 magnitude: 0
@@ -374,24 +374,24 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --no-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --no-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --neg-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 6
 integer: 0
 magnitude: 0
@@ -399,30 +399,30 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() works' '
-	test-parse-options -bb --or4 > output 2> output.err &&
+	test-parse-options -bb --or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() works' '
-	test-parse-options -bb --no-neg-or4 > output 2> output.err &&
+	test-parse-options -bb --no-neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
-	test-parse-options + + + + + + > output 2> output.err &&
+	test-parse-options + + + + + + >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 0
 integer: 12345
 magnitude: 0
@@ -430,13 +430,13 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
 
 test_expect_success 'OPT_NUMBER_CALLBACK() works' '
-	test-parse-options -12345 > output 2> output.err &&
+	test-parse-options -12345 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
@@ -449,7 +449,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -460,7 +460,7 @@ test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test_cmp expect output
 '
 
-cat >>expect <<'EOF'
+cat >>expect <<EOF
 list: foo
 list: bar
 list: baz
diff --git a/test-parse-options.c b/test-parse-options.c
index 2c8c8f1..86afa98 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -90,7 +90,7 @@ int main(int argc, char **argv)
 	printf("string: %s\n", string ? string : "(not set)");
 	printf("abbrev: %d\n", abbrev);
 	printf("verbose: %d\n", verbose);
-	printf("quiet: %s\n", quiet ? "yes" : "no");
+	printf("quiet: %d\n", quiet);
 	printf("dry run: %s\n", dry_run ? "yes" : "no");
 	printf("file: %s\n", file ? file : "(not set)");
 

--
https://github.com/git/git/pull/218

[PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

Make the fake "editor" store output of grep in a file so that we can
see how many diffs were contained in the message and use them in
individual tests where ever it is required. Also use write_script()
to create the fake "editor".

A subsequent commit will introduce scenarios where it is important to be
able to exactly determine how many diffs were present.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

Previous version of this patch:
 - [v10]: $gmane/288820

Changes this version wrt previous one:
I decided to include no of diffs in every test and rewrote the commit
message so as to sell this idea. This was given as an option to me by
Eric and the other option being to drop unnecessary testing of lines
where it isn't required. Also this patch uses a suggestion given by Eric
to make the "editor" look more clean as compared to the editor in my
previous version.
---
 t/t7507-commit-verbose.sh | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..0f28a86 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -3,11 +3,10 @@
 test_description='verbose commit template'
 . ./test-lib.sh
 
-cat >check-for-diff <<EOF
-#!$SHELL_PATH
-exec grep '^diff --git' "\$1"
+write_script "check-for-diff" <<\EOF &&
+grep '^diff --git' "$1" >out
+exit 0
 EOF
-chmod +x check-for-diff
 test_set_editor "$PWD/check-for-diff"
 
 cat >message <<'EOF'
@@ -23,7 +22,8 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'initial commit shows verbose diff' '
-	git commit --amend -v
+	git commit --amend -v &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'second commit' '
@@ -39,13 +39,15 @@ check_message() {
 
 test_expect_success 'verbose diff is stripped out' '
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
 	git config diff.mnemonicprefix true &&
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 cat >diff <<'EOF'

--
https://github.com/git/git/pull/218

[PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

The reason to make it respect "unspecified" values is to give the
ability to differentiate whether `--option` or `--no-option` was
specified at all. "unspecified" values should be in the form of negative
values. If initial value is set to negative and `--option` specified
then it will reflect the number of occurrences (counting done from 0),
if `--no-option` is specified then it will reflect 0 and if nothing at
all is given then it will retain its negative value.

This change will not affect existing users of COUNTUP at all, as long as
they use the initial value of 0 (or more).

Force uses the "unspecified" value in conjunction with OPT__FORCE in
builtin/clean.c in a different way to handle its config which
munges the "-1" into 0 before we get to parse_options.

To test this behavior "verbose" is set to "unspecified" while quiet is
set to 0 which will test the new behavior with all sets of values.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v10] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v9] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes introduced:
Use a different language in commit message to make the change and its
utility more clear. Also added some points as to where this patch could
break but it doesn't. Include tests to test this behavior by modifying
test-parse-options.c and t/t0040-parse-options.sh as requested by SZEDER
and reminded by Eric.

Please Note: The diff might seem improper especially the part where I
have introduced some continuous lines but this is a logical error by git
diff (nothing could be done about it) and thus the changes will be
clearly visible with the original file itself.
---
 Documentation/technical/api-parse-options.txt |  8 ++++--
 parse-options.c                               |  8 +++++-
 t/t0040-parse-options.sh                      | 39 ++++++++++++++++++++-------
 test-parse-options.c                          |  3 ++-
 4 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..8908bf7 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,12 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	Each use of `--option` increments `int_var`, starting from zero
+	(even if initially negative), and `--no-option` resets it to
+	zero. To determine if `--option` or `--no-option` was set at
+	all, set `int_var` to a negative value, and if it is still
+	negative after parse_options(), then neither `--option` nor
+	`--no-option` was seen.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..86d30bd 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
-		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
+		if (unset)
+			*(int *)opt->value = 0;
+		else {
+			if (*(int *)opt->value < 0)
+				*(int *)opt->value = 0;
+			*(int *)opt->value += 1;
+		}
 		return 0;
 
 	case OPTION_SET_INT:
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 2dcbdc0..275bb64 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -63,7 +63,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -211,7 +211,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -234,7 +234,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -263,7 +263,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -302,7 +302,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -322,7 +322,7 @@ magnitude: 0
 timestamp: 1
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 1
 dry run: no
 file: (not set)
@@ -344,7 +344,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -373,7 +373,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -398,7 +398,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -429,7 +429,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -454,6 +454,25 @@ dry run: no
 file: (not set)
 EOF
 
+test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
+	test-parse-options --no-verbose >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
+
+cat >expect <<EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: -1
+quiet: 0
+dry run: no
+file: (not set)
+EOF
+
 test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test-parse-options --no-ambig >output 2>output.err &&
 	test_must_be_empty output.err &&
diff --git a/test-parse-options.c b/test-parse-options.c
index 86afa98..f02c275 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -7,7 +7,8 @@ static int integer = 0;
 static unsigned long magnitude = 0;
 static unsigned long timestamp;
 static int abbrev = 7;
-static int verbose = 0, dry_run = 0, quiet = 0;
+static int verbose = -1; /* unspecified */
+static int dry_run = 0, quiet = 0;
 static char *string = NULL;
 static char *file = NULL;
 static int ambiguous;

--
https://github.com/git/git/pull/218

[PATCH v11 4/4] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:
 - [v10] $gmane/288820
 - [v9] $gmane/288820
 - [v8] $gmane/288820
 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

Changes with respect to the previous patch:
 - Before config_verbose reacted to only -1 but henceforth it will react
   to every negative integer.
 - Use test_line_count for consistency
 - Add 1 more test for to check whether git status breaks
 - Add more tests to test whether commit.verbose works fine with all
   integers suggested by Eric Sunshine.
   Note: One might think some tests are extra but I think that it will
   be better to include them as they "complete the continuity" thus
   generalising the series which will make the patch even more clearer.

SZEDER pointed out a bug in v9 which broke status. verbose being set to
-1, returns true in the `if(verbose)` statement which gives a verbose
output. So thus, it is required to reset it to 0 if it was -1. This will
work fine when status is passed with --verbose and --no-verbose as they
both reflect non-negative values.
---
 Documentation/config.txt     |   4 +
 Documentation/git-commit.txt |   3 +-
 builtin/commit.c             |  14 +++-
 t/t7507-commit-verbose.sh    | 175 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 194 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..96e6190 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1354,6 +1356,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 			     builtin_status_usage, 0);
 	finalize_colopts(&s.colopts, -1);
 	finalize_deferred_config(&s);
+	if (verbose == -1)
+		verbose = 0;
 
 	handle_untracked_files_arg(&s);
 	if (show_ignored_in_status)
@@ -1505,6 +1509,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1663,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+	if (verbose == -1)
+		verbose = (config_verbose < 0) ? 0 : config_verbose;
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 0f28a86..7c79484 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -98,4 +98,179 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'set up -v -v' '
+	echo dirty >file &&
+	echo dirty >file2 &&
+	git add file2
+'
+test_expect_success 'commit.verbose true and --verbose omitted' '
+	git -c commit.verbose=true commit -F message &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose true and --verbose' '
+	git -c commit.verbose=true commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose true and -v -v' '
+	git -c commit.verbose=true commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose true and --no-verbose' '
+	git -c commit.verbose=true commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose false and --verbose' '
+	git -c commit.verbose=false commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose false and -v -v' '
+	git -c commit.verbose=false commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose false and --verbose omitted' '
+	git -c commit.verbose=false commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose false and --no-verbose' '
+	git -c commit.verbose=false commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=-2 and --verbose omitted' '
+	git -c commit.verbose=-2 commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=-1 and --verbose omitted' '
+	git -c commit.verbose=-1 commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=0 and --verbose omitted' '
+	git -c commit.verbose=0 commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=1 and --verbose omitted' '
+	git -c commit.verbose=1 commit --amend &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=2 and --verbose omitted' '
+	git -c commit.verbose=2 commit --amend &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit-verbose=3 and --verbose omitted' '
+	git -c commit.verbose=3 commit --amend &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=-2 and --verbose' '
+	git -c commit.verbose=-2 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=-1 and --verbose' '
+	git -c commit.verbose=-1 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=0 and --verbose' '
+	git -c commit.verbose=0 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=1 and --verbose' '
+	git -c commit.verbose=1 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=2 and --verbose' '
+	git -c commit.verbose=2 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=3 and --verbose' '
+	git -c commit.verbose=3 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=-2 and -v -v' '
+	git -c commit.verbose=-2 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=-1 and -v -v' '
+	git -c commit.verbose=-1 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=0 and -v -v' '
+	git -c commit.verbose=0 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=1 and -v -v' '
+	git -c commit.verbose=1 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=2 and -v -v' '
+	git -c commit.verbose=2 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=3 and -v -v' '
+	git -c commit.verbose=3 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=-2 and --no-verbose' '
+	git -c commit.verbose=-2 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=-1 and --no-verbose' '
+	git -c commit.verbose=-1 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=0 and --no-verbose' '
+	git -c commit.verbose=0 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=1 and --no-verbose' '
+	git -c commit.verbose=1 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=2 and --no-verbose' '
+	git -c commit.verbose=2 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=3 and --no-verbose' '
+	git -c commit.verbose=3 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
+test_expect_success 'status does not verbose without --verbose' '
+	git status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/218

Re: [PATCH v11 1/4] test-parse-options: print quiet as integer

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> Current implementation of parse-options.c treats OPT__QUIET() as integer
> and not boolean and thus it is more appropriate to print it as integer
> to avoid confusion.
>
> While at it, fix some style issues.

I counted the changes in t0040 and you have _more_ style fixes than
the real change.  That is not "while at it".

While I welcome the style fix, it is better done as a preparatory
clean-up step before the real change.

> ---

Missing sign-off.

> -cat > typo.err << EOF
> +cat >typo.err <<EOF
>  error: did you mean \`--boolean\` (with two dashes ?)
>  EOF

If your "style cleanup" patch were separate, you could fix this (and
other that have backslash escape inside the here-document) further
to something like this:

	cat >type.err <<\EOF
	error: did you mean `--boolean` (with two dashes ?)
        EOF

Thanks.

Re: [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> Make the fake "editor" store output of grep in a file so that we can
> see how many diffs were contained in the message and use them in
> individual tests where ever it is required. Also use write_script()
> to create the fake "editor".
>
> A subsequent commit will introduce scenarios where it is important to be
> able to exactly determine how many diffs were present.
>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>
> Previous version of this patch:
>  - [v10]: $gmane/288820
>
> Changes this version wrt previous one:
> I decided to include no of diffs in every test and rewrote the commit
> message so as to sell this idea. This was given as an option to me by
> Eric and the other option being to drop unnecessary testing of lines
> where it isn't required. Also this patch uses a suggestion given by Eric
> to make the "editor" look more clean as compared to the editor in my
> previous version.
> ---

OK, by always exiting 0 from the editor, you do not interfere with
the "git commit" that invoked it, and you inspect the editor's
finding after "git commit" returns.  The approach taken by this
patch looks a lot more sensible than the previous one.

You'd need the three-dash right before "Previous version of..."
line, though.

>  t/t7507-commit-verbose.sh | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> index 2ddf28c..0f28a86 100755
> --- a/t/t7507-commit-verbose.sh
> +++ b/t/t7507-commit-verbose.sh
> @@ -3,11 +3,10 @@
>  test_description='verbose commit template'
>  . ./test-lib.sh
>  
> -cat >check-for-diff <<EOF
> -#!$SHELL_PATH
> -exec grep '^diff --git' "\$1"
> +write_script "check-for-diff" <<\EOF &&
> +grep '^diff --git' "$1" >out
> +exit 0
>  EOF
> -chmod +x check-for-diff
>  test_set_editor "$PWD/check-for-diff"
>  
>  cat >message <<'EOF'
> @@ -23,7 +22,8 @@ test_expect_success 'setup' '
>  '
>  
>  test_expect_success 'initial commit shows verbose diff' '
> -	git commit --amend -v
> +	git commit --amend -v &&
> +	test_line_count = 1 out
>  '
>  
>  test_expect_success 'second commit' '
> @@ -39,13 +39,15 @@ check_message() {
>  
>  test_expect_success 'verbose diff is stripped out' '
>  	git commit --amend -v &&
> -	check_message message
> +	check_message message &&
> +	test_line_count = 1 out
>  '
>  
>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
>  	git config diff.mnemonicprefix true &&
>  	git commit --amend -v &&
> -	check_message message
> +	check_message message &&
> +	test_line_count = 1 out
>  '
>  
>  cat >diff <<'EOF'
>
> --
> https://github.com/git/git/pull/218

Re: [PATCH v11 1/4] test-parse-options: print quiet as integer

[Pranit Bauva]

On Thu, Mar 31, 2016 at 11:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>> and not boolean and thus it is more appropriate to print it as integer
>> to avoid confusion.
>>
>> While at it, fix some style issues.
>
> I counted the changes in t0040 and you have _more_ style fixes than
> the real change.  That is not "while at it".
>
> While I welcome the style fix, it is better done as a preparatory
> clean-up step before the real change.

Okay. I thought this was a minor change so I squashed it together. I
will separate it though.

> Missing sign-off.

Will include this

>> -cat > typo.err << EOF
>> +cat >typo.err <<EOF
>>  error: did you mean \`--boolean\` (with two dashes ?)
>>  EOF
>
> If your "style cleanup" patch were separate, you could fix this (and
> other that have backslash escape inside the here-document) further
> to something like this:
>
>         cat >type.err <<\EOF
>         error: did you mean `--boolean` (with two dashes ?)
>         EOF
>
> Thanks.

Will include this.

Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> This change will not affect existing users of COUNTUP at all, as long as
> they use the initial value of 0 (or more).
>
> Force uses the "unspecified" value in conjunction with OPT__FORCE in
> builtin/clean.c in a different way to handle its config which
> munges the "-1" into 0 before we get to parse_options.

These two paragraphs leave the readers wondering what the conclusion
is.  "it is OK as long as..." makes us wonder "so are there users
that do not satisfy that condition?"  "in a different way" makes us
wonder "Does this change break builtin/clean.c because COUNTUP is
used in a different way?".

	This change does not affect existing users of COUNTUP,
	because they all use the initial value of 0 (or more).

	Note that builtin/clean.c initializes the variable used with
	OPT__FORCE (which uses OPT_COUNTUP()) to a negative value,
	but it is set to either 0 or 1 by reading the configuration
	before the code calls parse_options(), i.e. as far as
	parse_options() is concerned, the initial value of the
	variable is not negative.

perhaps?

>  `OPT_COUNTUP(short, long, &int_var, description)`::
>  	Introduce a count-up option.
> -	`int_var` is incremented on each use of `--option`, and
> -	reset to zero with `--no-option`.
> +	Each use of `--option` increments `int_var`, starting from zero
> +	(even if initially negative), and `--no-option` resets it to
> +	zero. To determine if `--option` or `--no-option` was set at
> +	all, set `int_var` to a negative value, and if it is still
> +	negative after parse_options(), then neither `--option` nor
> +	`--no-option` was seen.
>  
>  `OPT_BIT(short, long, &int_var, description, mask)`::
>  	Introduce a boolean option.
> diff --git a/parse-options.c b/parse-options.c
> index 47a9192..86d30bd 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
>  		return 0;
>  
>  	case OPTION_COUNTUP:
> -		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
> +		if (unset)
> +			*(int *)opt->value = 0;
> +		else {
> +			if (*(int *)opt->value < 0)
> +				*(int *)opt->value = 0;
> +			*(int *)opt->value += 1;
> +		}
>  		return 0;
>  
>  	case OPTION_SET_INT:

The new behaviour given by the patch looks very sensible, but I
wonder if this is easier to reason about:

	case OPTION_COUNTUP:
+		if (*(int *)opt->value < 0)
+			*(int *)opt->value = 0;
		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;

That is, upon hitting this case arm, we know that an explicit option
was given from the command line, so the "unspecified" initial value,
if it is still there, gets reset to 0, and after doing that, we just
do the usual thing.

Re: [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

On Thu, Mar 31, 2016 at 11:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> Make the fake "editor" store output of grep in a file so that we can
>> see how many diffs were contained in the message and use them in
>> individual tests where ever it is required. Also use write_script()
>> to create the fake "editor".
>>
>> A subsequent commit will introduce scenarios where it is important to be
>> able to exactly determine how many diffs were present.
>>
>> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>>
>> Previous version of this patch:
>>  - [v10]: $gmane/288820
>>
>> Changes this version wrt previous one:
>> I decided to include no of diffs in every test and rewrote the commit
>> message so as to sell this idea. This was given as an option to me by
>> Eric and the other option being to drop unnecessary testing of lines
>> where it isn't required. Also this patch uses a suggestion given by Eric
>> to make the "editor" look more clean as compared to the editor in my
>> previous version.
>> ---
>
> OK, by always exiting 0 from the editor, you do not interfere with
> the "git commit" that invoked it, and you inspect the editor's
> finding after "git commit" returns.  The approach taken by this
> patch looks a lot more sensible than the previous one.
>
> You'd need the three-dash right before "Previous version of..."
> line, though.

That's silly of me to forget this. Will do it.

>>  t/t7507-commit-verbose.sh | 16 +++++++++-------
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>> index 2ddf28c..0f28a86 100755
>> --- a/t/t7507-commit-verbose.sh
>> +++ b/t/t7507-commit-verbose.sh
>> @@ -3,11 +3,10 @@
>>  test_description='verbose commit template'
>>  . ./test-lib.sh
>>
>> -cat >check-for-diff <<EOF
>> -#!$SHELL_PATH
>> -exec grep '^diff --git' "\$1"
>> +write_script "check-for-diff" <<\EOF &&
>> +grep '^diff --git' "$1" >out
>> +exit 0
>>  EOF
>> -chmod +x check-for-diff
>>  test_set_editor "$PWD/check-for-diff"
>>
>>  cat >message <<'EOF'
>> @@ -23,7 +22,8 @@ test_expect_success 'setup' '
>>  '
>>
>>  test_expect_success 'initial commit shows verbose diff' '
>> -     git commit --amend -v
>> +     git commit --amend -v &&
>> +     test_line_count = 1 out
>>  '
>>
>>  test_expect_success 'second commit' '
>> @@ -39,13 +39,15 @@ check_message() {
>>
>>  test_expect_success 'verbose diff is stripped out' '
>>       git commit --amend -v &&
>> -     check_message message
>> +     check_message message &&
>> +     test_line_count = 1 out
>>  '
>>
>>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
>>       git config diff.mnemonicprefix true &&
>>       git commit --amend -v &&
>> -     check_message message
>> +     check_message message &&
>> +     test_line_count = 1 out
>>  '
>>
>>  cat >diff <<'EOF'
>>
>> --
>> https://github.com/git/git/pull/218

Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

On Fri, Apr 1, 2016 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> This change will not affect existing users of COUNTUP at all, as long as
>> they use the initial value of 0 (or more).
>>
>> Force uses the "unspecified" value in conjunction with OPT__FORCE in
>> builtin/clean.c in a different way to handle its config which
>> munges the "-1" into 0 before we get to parse_options.
>
> These two paragraphs leave the readers wondering what the conclusion
> is.  "it is OK as long as..." makes us wonder "so are there users
> that do not satisfy that condition?"  "in a different way" makes us
> wonder "Does this change break builtin/clean.c because COUNTUP is
> used in a different way?".
>
>         This change does not affect existing users of COUNTUP,
>         because they all use the initial value of 0 (or more).
>
>         Note that builtin/clean.c initializes the variable used with
>         OPT__FORCE (which uses OPT_COUNTUP()) to a negative value,
>         but it is set to either 0 or 1 by reading the configuration
>         before the code calls parse_options(), i.e. as far as
>         parse_options() is concerned, the initial value of the
>         variable is not negative.
>
> perhaps?

Thanks again for the help with the comit message. I sometimes fail to
see how first time readers will infer from the message.

>>  `OPT_COUNTUP(short, long, &int_var, description)`::
>>       Introduce a count-up option.
>> -     `int_var` is incremented on each use of `--option`, and
>> -     reset to zero with `--no-option`.
>> +     Each use of `--option` increments `int_var`, starting from zero
>> +     (even if initially negative), and `--no-option` resets it to
>> +     zero. To determine if `--option` or `--no-option` was set at
>> +     all, set `int_var` to a negative value, and if it is still
>> +     negative after parse_options(), then neither `--option` nor
>> +     `--no-option` was seen.
>>
>>  `OPT_BIT(short, long, &int_var, description, mask)`::
>>       Introduce a boolean option.
>> diff --git a/parse-options.c b/parse-options.c
>> index 47a9192..86d30bd 100644
>> --- a/parse-options.c
>> +++ b/parse-options.c
>> @@ -110,7 +110,13 @@ static int get_value(struct parse_opt_ctx_t *p,
>>               return 0;
>>
>>       case OPTION_COUNTUP:
>> -             *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>> +             if (unset)
>> +                     *(int *)opt->value = 0;
>> +             else {
>> +                     if (*(int *)opt->value < 0)
>> +                             *(int *)opt->value = 0;
>> +                     *(int *)opt->value += 1;
>> +             }
>>               return 0;
>>
>>       case OPTION_SET_INT:
>
> The new behaviour given by the patch looks very sensible, but I
> wonder if this is easier to reason about:
>
>         case OPTION_COUNTUP:
> +               if (*(int *)opt->value < 0)
> +                       *(int *)opt->value = 0;
>                 *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>
> That is, upon hitting this case arm, we know that an explicit option
> was given from the command line, so the "unspecified" initial value,
> if it is still there, gets reset to 0, and after doing that, we just
> do the usual thing.

This does look cleaner. Nice thinking that there is no need to
actually specify when it gets 0. It gets 0 no matter what as long as
OPTION_COUNTUP is speficied in any format (with or without --no) and
variable is "unspecified".

Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> On Fri, Apr 1, 2016 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>         case OPTION_COUNTUP:
>> +               if (*(int *)opt->value < 0)
>> +                       *(int *)opt->value = 0;
>>                 *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>>
>> That is, upon hitting this case arm, we know that an explicit option
>> was given from the command line, so the "unspecified" initial value,
>> if it is still there, gets reset to 0, and after doing that, we just
>> do the usual thing.
>
> This does look cleaner. Nice thinking that there is no need to
> actually specify when it gets 0. It gets 0 no matter what as long as
> OPTION_COUNTUP is speficied in any format (with or without --no) and
> variable is "unspecified".

I do not think there is any planned users of such an enhancement,
but the above points us into a future possibility to be able to do
this:

        case OPTION_COUNTUP:
+               if (*(int *)opt->value < 0)
+                       *(int *)opt->value = -*(int *)opt->value - 1;
                *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;

That is, by using "-2" as the "unspecified" value, you can start
counting up from 2 (i.e. the presence of the option resets the
variable to 1 and then the option being not "unset" increments it)
if your application wants to.

Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

On Fri, Apr 1, 2016 at 1:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> On Fri, Apr 1, 2016 at 12:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>>         case OPTION_COUNTUP:
>>> +               if (*(int *)opt->value < 0)
>>> +                       *(int *)opt->value = 0;
>>>                 *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>>>
>>> That is, upon hitting this case arm, we know that an explicit option
>>> was given from the command line, so the "unspecified" initial value,
>>> if it is still there, gets reset to 0, and after doing that, we just
>>> do the usual thing.
>>
>> This does look cleaner. Nice thinking that there is no need to
>> actually specify when it gets 0. It gets 0 no matter what as long as
>> OPTION_COUNTUP is speficied in any format (with or without --no) and
>> variable is "unspecified".
>
> I do not think there is any planned users of such an enhancement,
> but the above points us into a future possibility to be able to do
> this:
>
>         case OPTION_COUNTUP:
> +               if (*(int *)opt->value < 0)
> +                       *(int *)opt->value = -*(int *)opt->value - 1;
>                 *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>
> That is, by using "-2" as the "unspecified" value, you can start
> counting up from 2 (i.e. the presence of the option resets the
> variable to 1 and then the option being not "unset" increments it)
> if your application wants to.

I am not very familiar with Git community but I think including a new
feature to use our existing library (who's functionality isn't
required as for now) can trigger some creative thoughts in minds of
other developers which will make them think "How could this be used?".
This could lead to some exciting ideas on improving the UI of git.
Having something actually in hand gives you a confidence, rather than
knowing that you could grab it whenever it is needed.

Also, when such an idea for new feature comes up, it is better to
implement it because let's say some developer is stuck in future and
this new feature could help him but he doesn't have a clue that such a
discussion happened some time ago. Thus saving him time and further
effort.

Anyways, How is the convention in git for these type of futuristic ideas?

Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> Also, when such an idea for new feature comes up, it is better to
> implement it because let's say some developer is stuck in future and
> this new feature could help him but he doesn't have a clue that such a
> discussion happened some time ago. Thus saving him time and further
> effort.
>
> Anyways, How is the convention in git for these type of futuristic ideas?

Just keep it in mind without complicating the code, unless the idea
truly makes sense and has immediate use.

For example, I do not know how it would be useful to be able to
count up starting from 2 with an option --more that is COUNTUP, if
your --no-more would reset it to 0.

     git cmd --more ;# sets more=2
     git cmd --more --more ;# sets more=3
     git cmd --no-more --more ;# sets more=1, not more=2

[PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

The reason to make it respect "unspecified" values is to give the
ability to differentiate whether `--option` or `--no-option` was
specified at all. "unspecified" values should be in the form of negative
values. If initial value is set to negative and `--option` specified
then it will reflect the number of occurrences (counting done from 0),
if `--no-option` is specified then it will reflect 0 and if nothing at
all is given then it will retain its negative value.

This change will not affect existing users of COUNTUP, because they all
use the initial value of 0 (or more).

Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.

To test this behavior "verbose" is set to "unspecified" while quiet is
set to 0 which will test the new behavior with all sets of values.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v11] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v10] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v9] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes wrt previous version (v11):
 - Use bits of commit message provided by Junio.

Please Note: The diff might seem improper especially the part where I
have introduced some continuous lines but this is a logical error by git
diff (nothing could be done about it) and thus the changes will be
clearly visible with the original file itself.
---
 Documentation/technical/api-parse-options.txt |  8 ++++--
 parse-options.c                               |  2 ++
 t/t0040-parse-options.sh                      | 39 ++++++++++++++++++++-------
 test-parse-options.c                          |  3 ++-
 4 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..8908bf7 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,12 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	Each use of `--option` increments `int_var`, starting from zero
+	(even if initially negative), and `--no-option` resets it to
+	zero. To determine if `--option` or `--no-option` was set at
+	all, set `int_var` to a negative value, and if it is still
+	negative after parse_options(), then neither `--option` nor
+	`--no-option` was seen.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..312a85d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,6 +110,8 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
+		if (*(int *)opt->value < 0)
+			*(int *)opt->value = 0;
 		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
 		return 0;
 
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 302c315..bfd8dea 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -63,7 +63,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -211,7 +211,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -234,7 +234,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -263,7 +263,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -302,7 +302,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -322,7 +322,7 @@ magnitude: 0
 timestamp: 1
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 1
 dry run: no
 file: (not set)
@@ -344,7 +344,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -373,7 +373,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -398,7 +398,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -429,7 +429,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -454,6 +454,25 @@ dry run: no
 file: (not set)
 EOF
 
+test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
+	test-parse-options --no-verbose >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
+
+cat >expect <<EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: -1
+quiet: 0
+dry run: no
+file: (not set)
+EOF
+
 test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test-parse-options --no-ambig >output 2>output.err &&
 	test_must_be_empty output.err &&
diff --git a/test-parse-options.c b/test-parse-options.c
index 86afa98..f02c275 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -7,7 +7,8 @@ static int integer = 0;
 static unsigned long magnitude = 0;
 static unsigned long timestamp;
 static int abbrev = 7;
-static int verbose = 0, dry_run = 0, quiet = 0;
+static int verbose = -1; /* unspecified */
+static int dry_run = 0, quiet = 0;
 static char *string = NULL;
 static char *file = NULL;
 static int ambiguous;

--
https://github.com/git/git/pull/218

[PATCH v12 2/5] test-parse-options: print quiet as integer

[Pranit Bauva]

Current implementation of parse-options.c treats OPT__QUIET() as integer
and not boolean and thus it is more appropriate to print it as integer
to avoid confusion.

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
 t/t0040-parse-options.sh | 26 +++++++++++++-------------
 test-parse-options.c     |  2 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index c6f205b..302c315 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -64,7 +64,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -164,7 +164,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 2
-quiet: no
+quiet: 0
 dry run: yes
 file: prefix/my.file
 EOF
@@ -184,7 +184,7 @@ timestamp: 0
 string: 321
 abbrev: 10
 verbose: 2
-quiet: no
+quiet: 0
 dry run: no
 file: prefix/fi.le
 EOF
@@ -212,7 +212,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: a1
@@ -235,7 +235,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -264,7 +264,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -303,7 +303,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: --quux
@@ -323,7 +323,7 @@ timestamp: 1
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: yes
+quiet: 1
 dry run: no
 file: (not set)
 arg 00: foo
@@ -345,7 +345,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -374,7 +374,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -399,7 +399,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -430,7 +430,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -449,7 +449,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
diff --git a/test-parse-options.c b/test-parse-options.c
index 2c8c8f1..86afa98 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -90,7 +90,7 @@ int main(int argc, char **argv)
 	printf("string: %s\n", string ? string : "(not set)");
 	printf("abbrev: %d\n", abbrev);
 	printf("verbose: %d\n", verbose);
-	printf("quiet: %s\n", quiet ? "yes" : "no");
+	printf("quiet: %d\n", quiet);
 	printf("dry run: %s\n", dry_run ? "yes" : "no");
 	printf("file: %s\n", file ? file : "(not set)");
 

--
https://github.com/git/git/pull/218

[PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

Make the fake "editor" store output of grep in a file so that we can
see how many diffs were contained in the message and use them in
individual tests where ever it is required. Also use write_script()
to create the fake "editor".

A subsequent commit will introduce scenarios where it is important to be
able to exactly determine how many diffs were present.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
Previous version of this patch:
 - [v11] : $gmane/28820
 - [v10]: $gmane/288820

Changes this version wrt previous one:
Include the triple dash which I previously forgot, pointed out by Junio.
---
 t/t7507-commit-verbose.sh | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..0f28a86 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -3,11 +3,10 @@
 test_description='verbose commit template'
 . ./test-lib.sh
 
-cat >check-for-diff <<EOF
-#!$SHELL_PATH
-exec grep '^diff --git' "\$1"
+write_script "check-for-diff" <<\EOF &&
+grep '^diff --git' "$1" >out
+exit 0
 EOF
-chmod +x check-for-diff
 test_set_editor "$PWD/check-for-diff"
 
 cat >message <<'EOF'
@@ -23,7 +22,8 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'initial commit shows verbose diff' '
-	git commit --amend -v
+	git commit --amend -v &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'second commit' '
@@ -39,13 +39,15 @@ check_message() {
 
 test_expect_success 'verbose diff is stripped out' '
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
 	git config diff.mnemonicprefix true &&
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 cat >diff <<'EOF'

--
https://github.com/git/git/pull/218

[PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

[Pranit Bauva]

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
Changes wrt previous version (v11):
 - This patch is a split up of patch 1/4 v11 as requested by Junio.
 - This patch uses the backslash with EOF as suggested by Junio
   for 2 tests namely "detect possible typos"
---
 t/t0040-parse-options.sh | 72 ++++++++++++++++++++++++------------------------
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 9be6411..c6f205b 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -7,7 +7,7 @@ test_description='our own option parser'
 
 . ./test-lib.sh
 
-cat > expect << EOF
+cat >expect <<EOF
 usage: test-parse-options <options>
 
     --yes                 get a boolean
@@ -49,7 +49,7 @@ Standard options
 EOF
 
 test_expect_success 'test help' '
-	test_must_fail test-parse-options -h > output 2> output.err &&
+	test_must_fail test-parse-options -h >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_i18ncmp expect output
 '
@@ -156,7 +156,7 @@ test_expect_success 'OPT_MAGNITUDE() 3giga' '
 	check magnitude: 3221225472 -m 3g
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -176,7 +176,7 @@ test_expect_success 'short options' '
 	test_must_be_empty output.err
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -204,7 +204,7 @@ test_expect_success 'missing required value' '
 	test_expect_code 129 test-parse-options --file
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 1
 integer: 13
 magnitude: 0
@@ -222,12 +222,12 @@ EOF
 
 test_expect_success 'intermingled arguments' '
 	test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
-		> output 2> output.err &&
+		>output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 0
 integer: 2
 magnitude: 0
@@ -241,13 +241,13 @@ file: (not set)
 EOF
 
 test_expect_success 'unambiguously abbreviated option' '
-	test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
+	test-parse-options --int 2 --boolean --no-bo >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'unambiguously abbreviated option with "="' '
-	test-parse-options --int=2 > output 2> output.err &&
+	test-parse-options --int=2 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
@@ -256,7 +256,7 @@ test_expect_success 'ambiguously abbreviated option' '
 	test_expect_code 129 test-parse-options --strin 123
 '
 
-cat > expect << EOF
+cat >expect <<EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -270,32 +270,32 @@ file: (not set)
 EOF
 
 test_expect_success 'non ambiguous option (after two options it abbreviates)' '
-	test-parse-options --st 123 > output 2> output.err &&
+	test-parse-options --st 123 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > typo.err << EOF
-error: did you mean \`--boolean\` (with two dashes ?)
+cat >typo.err <<\EOF
+error: did you mean `--boolean` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -boolean > output 2> output.err &&
+	test_must_fail test-parse-options -boolean >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > typo.err << EOF
-error: did you mean \`--ambiguous\` (with two dashes ?)
+cat >typo.err <<\EOF
+error: did you mean `--ambiguous` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -ambiguous > output 2> output.err &&
+	test_must_fail test-parse-options -ambiguous >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -310,12 +310,12 @@ arg 00: --quux
 EOF
 
 test_expect_success 'keep some options as arguments' '
-	test-parse-options --quux > output 2> output.err &&
+	test-parse-options --quux >output 2>output.err &&
 	test_must_be_empty output.err &&
-        test_cmp expect output
+	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -331,12 +331,12 @@ EOF
 
 test_expect_success 'OPT_DATE() works' '
 	test-parse-options -t "1970-01-01 00:00:01 +0000" \
-		foo -q > output 2> output.err &&
+		foo -q >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 Callback: "four", 0
 boolean: 5
 integer: 4
@@ -351,22 +351,22 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_CALLBACK() and OPT_BIT() work' '
-	test-parse-options --length=four -b -4 > output 2> output.err &&
+	test-parse-options --length=four -b -4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 Callback: "not set", 1
 EOF
 
 test_expect_success 'OPT_CALLBACK() and callback errors work' '
-	test_must_fail test-parse-options --no-length > output 2> output.err &&
+	test_must_fail test-parse-options --no-length >output 2>output.err &&
 	test_i18ncmp expect output &&
 	test_i18ncmp expect.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 1
 integer: 23
 magnitude: 0
@@ -380,18 +380,18 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --no-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --no-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --neg-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 6
 integer: 0
 magnitude: 0
@@ -405,24 +405,24 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() works' '
-	test-parse-options -bb --or4 > output 2> output.err &&
+	test-parse-options -bb --or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() works' '
-	test-parse-options -bb --no-neg-or4 > output 2> output.err &&
+	test-parse-options -bb --no-neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
-	test-parse-options + + + + + + > output 2> output.err &&
+	test-parse-options + + + + + + >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<EOF
 boolean: 0
 integer: 12345
 magnitude: 0
@@ -436,7 +436,7 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_NUMBER_CALLBACK() works' '
-	test-parse-options -12345 > output 2> output.err &&
+	test-parse-options -12345 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
@@ -460,7 +460,7 @@ test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test_cmp expect output
 '
 
-cat >>expect <<'EOF'
+cat >>expect <<EOF
 list: foo
 list: bar
 list: baz

--
https://github.com/git/git/pull/218

[PATCH v12 5/5] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:
 - [v11] $gmane/288820
 - [v10] $gmane/288820
 - [v9] $gmane/288820
 - [v8] $gmane/288820
 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

   Note: One might think some tests are extra but I think that it will
   be better to include them as they "complete the continuity" thus
   generalising the series which will make the patch even more clearer.
---
 Documentation/config.txt     |   4 +
 Documentation/git-commit.txt |   3 +-
 builtin/commit.c             |  14 +++-
 t/t7507-commit-verbose.sh    | 175 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 194 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..96e6190 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1354,6 +1356,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 			     builtin_status_usage, 0);
 	finalize_colopts(&s.colopts, -1);
 	finalize_deferred_config(&s);
+	if (verbose == -1)
+		verbose = 0;
 
 	handle_untracked_files_arg(&s);
 	if (show_ignored_in_status)
@@ -1505,6 +1509,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1663,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+	if (verbose == -1)
+		verbose = (config_verbose < 0) ? 0 : config_verbose;
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 0f28a86..7c79484 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -98,4 +98,179 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'set up -v -v' '
+	echo dirty >file &&
+	echo dirty >file2 &&
+	git add file2
+'
+test_expect_success 'commit.verbose true and --verbose omitted' '
+	git -c commit.verbose=true commit -F message &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose true and --verbose' '
+	git -c commit.verbose=true commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose true and -v -v' '
+	git -c commit.verbose=true commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose true and --no-verbose' '
+	git -c commit.verbose=true commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose false and --verbose' '
+	git -c commit.verbose=false commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose false and -v -v' '
+	git -c commit.verbose=false commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose false and --verbose omitted' '
+	git -c commit.verbose=false commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose false and --no-verbose' '
+	git -c commit.verbose=false commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=-2 and --verbose omitted' '
+	git -c commit.verbose=-2 commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=-1 and --verbose omitted' '
+	git -c commit.verbose=-1 commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=0 and --verbose omitted' '
+	git -c commit.verbose=0 commit --amend &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=1 and --verbose omitted' '
+	git -c commit.verbose=1 commit --amend &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=2 and --verbose omitted' '
+	git -c commit.verbose=2 commit --amend &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit-verbose=3 and --verbose omitted' '
+	git -c commit.verbose=3 commit --amend &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=-2 and --verbose' '
+	git -c commit.verbose=-2 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=-1 and --verbose' '
+	git -c commit.verbose=-1 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=0 and --verbose' '
+	git -c commit.verbose=0 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=1 and --verbose' '
+	git -c commit.verbose=1 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=2 and --verbose' '
+	git -c commit.verbose=2 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=3 and --verbose' '
+	git -c commit.verbose=3 commit --amend --verbose &&
+	test_line_count = 1 out
+'
+
+test_expect_success 'commit.verbose=-2 and -v -v' '
+	git -c commit.verbose=-2 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=-1 and -v -v' '
+	git -c commit.verbose=-1 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=0 and -v -v' '
+	git -c commit.verbose=0 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=1 and -v -v' '
+	git -c commit.verbose=1 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=2 and -v -v' '
+	git -c commit.verbose=2 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=3 and -v -v' '
+	git -c commit.verbose=3 commit --amend -v -v &&
+	test_line_count = 2 out
+'
+
+test_expect_success 'commit.verbose=-2 and --no-verbose' '
+	git -c commit.verbose=-2 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=-1 and --no-verbose' '
+	git -c commit.verbose=-1 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=0 and --no-verbose' '
+	git -c commit.verbose=0 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=1 and --no-verbose' '
+	git -c commit.verbose=1 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=2 and --no-verbose' '
+	git -c commit.verbose=2 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'commit.verbose=3 and --no-verbose' '
+	git -c commit.verbose=3 commit --amend --no-verbose &&
+	test_line_count = 0 out
+'
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
+test_expect_success 'status does not verbose without --verbose' '
+	git status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/218

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

[Eric Sunshine]

On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> @@ -7,7 +7,7 @@ test_description='our own option parser'
>
>  . ./test-lib.sh
>
> -cat > expect << EOF
> +cat >expect <<EOF
>  usage: test-parse-options <options>
>      --yes                 get a boolean

It would be better to use <<\EOF for this one to make it clear that no
interpolation is desired in the heredoc.

> @@ -156,7 +156,7 @@ test_expect_success 'OPT_MAGNITUDE() 3giga' '
>         check magnitude: 3221225472 -m 3g
>  '
>
> -cat > expect << EOF
> +cat >expect <<EOF

Ditto: <<\EOF

Same applies to all similar heredocs in subsequent tests where
interpolation is not desired.

>  boolean: 2
>  integer: 1729
>  magnitude: 16384
> @@ -310,12 +310,12 @@ arg 00: --quux
>  EOF
>
>  test_expect_success 'keep some options as arguments' '
> -       test-parse-options --quux > output 2> output.err &&
> +       test-parse-options --quux >output 2>output.err &&
>         test_must_be_empty output.err &&
> -        test_cmp expect output
> +       test_cmp expect output

Okay, this is a whitespace change (spaces -> tab).

>  '
> @@ -460,7 +460,7 @@ test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
> -cat >>expect <<'EOF'
> +cat >>expect <<EOF

This is not a desirable change. This heredoc does not require
interpolation, so you don't want to turn it into a form which does
interpolate. For style consistency, therefore, you should change 'EOF'
to \EOF.

>  list: foo
>  list: bar
>  list: baz

Re: [PATCH v12 2/5] test-parse-options: print quiet as integer

[Eric Sunshine]

On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Current implementation of parse-options.c treats OPT__QUIET() as integer
> and not boolean and thus it is more appropriate to print it as integer
> to avoid confusion.

I can buy this line of reasoning, however, it would be even easier to
sell the change if you cited an existing client (a git command) which
actually respects multiple quiet levels. Are there any?

More importantly, though, this change implies that you should also add
tests to ensure that the quiet level is indeed incremented with each
--quiet, just as "-vv" and "--verbose --verbose" are already tested.
You might be able to include such new tests directly in this patch as
long as the commit message is clear about it, or add them in a
separate patch.

By the way, I don't see any tests to ensure that --no-verbose and
--no-quiet reset those respective values to 0. A separate patch which
adds such tests would be nice (unless such tests already exist and I
merely missed them).

> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
>  t/t0040-parse-options.sh | 26 +++++++++++++-------------
>  test-parse-options.c     |  2 +-
>  2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> index c6f205b..302c315 100755
> --- a/t/t0040-parse-options.sh
> +++ b/t/t0040-parse-options.sh
> @@ -64,7 +64,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -164,7 +164,7 @@ timestamp: 0
>  string: 123
>  abbrev: 7
>  verbose: 2
> -quiet: no
> +quiet: 0
>  dry run: yes
>  file: prefix/my.file
>  EOF
> @@ -184,7 +184,7 @@ timestamp: 0
>  string: 321
>  abbrev: 10
>  verbose: 2
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: prefix/fi.le
>  EOF
> @@ -212,7 +212,7 @@ timestamp: 0
>  string: 123
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  arg 00: a1
> @@ -235,7 +235,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -264,7 +264,7 @@ timestamp: 0
>  string: 123
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -303,7 +303,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  arg 00: --quux
> @@ -323,7 +323,7 @@ timestamp: 1
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: yes
> +quiet: 1
>  dry run: no
>  file: (not set)
>  arg 00: foo
> @@ -345,7 +345,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -374,7 +374,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -399,7 +399,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -430,7 +430,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -449,7 +449,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> diff --git a/test-parse-options.c b/test-parse-options.c
> index 2c8c8f1..86afa98 100644
> --- a/test-parse-options.c
> +++ b/test-parse-options.c
> @@ -90,7 +90,7 @@ int main(int argc, char **argv)
>         printf("string: %s\n", string ? string : "(not set)");
>         printf("abbrev: %d\n", abbrev);
>         printf("verbose: %d\n", verbose);
> -       printf("quiet: %s\n", quiet ? "yes" : "no");
> +       printf("quiet: %d\n", quiet);
>         printf("dry run: %s\n", dry_run ? "yes" : "no");
>         printf("file: %s\n", file ? file : "(not set)");

Re: [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Eric Sunshine]

On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> The reason to make it respect "unspecified" values is to give the
> ability to differentiate whether `--option` or `--no-option` was
> specified at all. "unspecified" values should be in the form of negative
> values. If initial value is set to negative and `--option` specified
> then it will reflect the number of occurrences (counting done from 0),
> if `--no-option` is specified then it will reflect 0 and if nothing at
> all is given then it will retain its negative value.

Thanks, this rewrite does a better job of explaining the aim of the
change and how a client can take advantage of it. However, with my
"first-time reader" hat on, I still have some trouble digesting it as
a coherent whole. I wonder if a rewrite like this would help?

    OPT_COUNTUP() merely increments the counter upon --option, and
    resets it to 0 upon --no-option, which means that there is no
    "unspecified" value with which a client can initialize the
    counter to determine whether or not --[no-]option was seen at
    all.

    Make OPT_COUNTUP() treat any negative number as an "unspecified"
    value to address this shortcoming. In particular, if a client
    initializes the counter to -1, then if it is still -1 after
    parse_options(), then neither --option nor --no-option was seen;
    if it is 0, then --no-option was seen last, and if it is 1 or
    greater, than --option was seen last.

> This change will not affect existing users of COUNTUP, because they all
> use the initial value of 0 (or more).

    "This change does not affect behavior of existing clients of..."

> Note that builtin/clean.c initializes the variable used with
> OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
> to either 0 or 1 by reading the configuration before the code calls
> parse_options(), i.e. as far as parse_options() is concerned, the
> initial value of the variable is not negative.
>
> To test this behavior "verbose" is set to "unspecified" while quiet is
> set to 0 which will test the new behavior with all sets of values.

I think you need to mention here that you're talking about test-parse-options.c
(and indirectly t0040) since it's otherwise too easy for the reader to
think that this paragraph is a continuation of the discussion about
OPT_COUNTUP()'s new behavior and how it won't impact existing tests,
rather than a new topic of its own (testing the behavior). Maybe say
something like this:

    To test the new behavior, augment the initial "verbose" setting
    of test-parse-options.c to be unspecified...

and then go on to say that, because "quiet" is still initialized to 0,
you have complete coverage. An alternative would be to split off the
new testing into its own patch, which would make this patch (which is
the real meat of the change) less noisy.

I actually expected you to add new functionality to
test-parse-options.c specifically to test OPT_COUNTUP() directly
rather than indirectly through --verbose and --quiet, however, I think
I can be sold on the approach you took for a couple reasons. First,
you have a genuine use-case for an "unspecified" --verbose value, so
changing test-parse-options.c's --verbose to start at -1 tests what
you ultimately care about. Second, since you retained 0-initialization
of --quiet, that case of OPT_COUNTUP() is still being tested.

What I find a bit disturbing about this approach is that you are
getting "full coverage" only because of current *implementation*, not
because you are explicitly testing for *expected* behavior. That is,
you get that coverage only while both OPT__VERBOSE() and OPT__QUIET()
are built atop OPT_COUNTUP(); if OPT__QUIET() is ever rewritten so it
no longer uses OPT_COUNTUP(), then the tests silently lose full
coverage. However, I may be over-worrying about the situation...

> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
> @@ -144,8 +144,12 @@ There are some macros to easily define options:
>  `OPT_COUNTUP(short, long, &int_var, description)`::
>         Introduce a count-up option.
> -       `int_var` is incremented on each use of `--option`, and
> -       reset to zero with `--no-option`.
> +       Each use of `--option` increments `int_var`, starting from zero
> +       (even if initially negative), and `--no-option` resets it to
> +       zero. To determine if `--option` or `--no-option` was set at

s/was set/was encountered/

> +       all, set `int_var` to a negative value, and if it is still

s/set `int_var`/initialize `int_var`/

> +       negative after parse_options(), then neither `--option` nor
> +       `--no-option` was seen.
> diff --git a/parse-options.c b/parse-options.c
> @@ -110,6 +110,8 @@ static int get_value(struct parse_opt_ctx_t *p,
>         case OPTION_COUNTUP:
> +               if (*(int *)opt->value < 0)
> +                       *(int *)opt->value = 0;
>                 *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;

This is nicer.

>                 return 0;
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> @@ -454,6 +454,25 @@ dry run: no
> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
> +       test-parse-options --no-verbose >output 2>output.err &&
> +       test_must_be_empty output.err &&
> +       test_cmp expect output
> +'

If you take the advice of my 2/5 review and add new tests (in a new
patch) which test --no-verbose and --no-quiet, then I think this new
test here can just go away since the case it cares about will already
be covered.

Re: [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs

[Eric Sunshine]

On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Make the fake "editor" store output of grep in a file so that we can
> see how many diffs were contained in the message and use them in
> individual tests where ever it is required. Also use write_script()
> to create the fake "editor".
>
> A subsequent commit will introduce scenarios where it is important to be
> able to exactly determine how many diffs were present.

These two sentences are backward. The "subsequent commit" bit is
justification for why you are making the "editor" store the output,
thus it belongs with the first paragraph. The bit about write_script()
is just a minor aside which can go in its own paragraph.

I think it's also important to explain that you're changing the
behavior of write_script() so that it always succeeds, regardless of
whether grep found diff headers or not, and to give the reason for
making this change ("so that you don't have to use 'test_must_fail'
for cases when no diff headers are expected and can instead easily use
'test_line_count = 0'").

The patch itself looks fine and is easy enough to read.

> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> index 2ddf28c..0f28a86 100755
> --- a/t/t7507-commit-verbose.sh
> +++ b/t/t7507-commit-verbose.sh
> @@ -3,11 +3,10 @@
>  test_description='verbose commit template'
>  . ./test-lib.sh
>
> -cat >check-for-diff <<EOF
> -#!$SHELL_PATH
> -exec grep '^diff --git' "\$1"
> +write_script "check-for-diff" <<\EOF &&
> +grep '^diff --git' "$1" >out
> +exit 0
>  EOF
> -chmod +x check-for-diff
>  test_set_editor "$PWD/check-for-diff"
>
>  cat >message <<'EOF'
> @@ -23,7 +22,8 @@ test_expect_success 'setup' '
>  '
>
>  test_expect_success 'initial commit shows verbose diff' '
> -       git commit --amend -v
> +       git commit --amend -v &&
> +       test_line_count = 1 out
>  '
>
>  test_expect_success 'second commit' '
> @@ -39,13 +39,15 @@ check_message() {
>
>  test_expect_success 'verbose diff is stripped out' '
>         git commit --amend -v &&
> -       check_message message
> +       check_message message &&
> +       test_line_count = 1 out
>  '
>
>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
>         git config diff.mnemonicprefix true &&
>         git commit --amend -v &&
> -       check_message message
> +       check_message message &&
> +       test_line_count = 1 out
>  '

Re: [PATCH v12 5/5] commit: add a commit.verbose config variable

[Eric Sunshine]

On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.
>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -1110,6 +1110,10 @@ commit.template::
> +commit.verbose::
> +       A boolean or int to specify the level of verbose with `git commit`.
> +       See linkgit:git-commit[1].

s/level of verbose with/verbosity level of/

> diff --git a/builtin/commit.c b/builtin/commit.c
> @@ -1505,6 +1509,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
> +       if (!strcmp(k, "commit.verbose")) {
> +               int is_bool;
> +               config_verbose = git_config_bool_or_int(k, v, &is_bool);
> +               return 0;
> +       }
> @@ -1654,6 +1663,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
>         argc = parse_and_validate_options(argc, argv, builtin_commit_options,
>                                           builtin_commit_usage,
>                                           prefix, current_head, &s);
> +       if (verbose == -1)
> +               verbose = (config_verbose < 0) ? 0 : config_verbose;

Okay, so this version compares 'config_verbose' with "< 0" rather than
"== -1" so it won't misbehave when someone sets config.verbose=-2 as
pointed out in [1]. Good.

> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> @@ -98,4 +98,179 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
> +test_expect_success 'set up -v -v' '

Style: "setup -v -v", not "set up -v -v"

> +       echo dirty >file &&
> +       echo dirty >file2 &&
> +       git add file2
> +'

Why this extra complexity when all you need for the "-v -v" case is:

    test_expect_success 'setup -v -v' '
        echo dirty >file
    '

as suggested by [1]? Try to keep unnecessary gunk out of the tests
(and code, in general) to avoid misleading readers into wondering if
something unusual is going on. Which leads to...

> +test_expect_success 'commit.verbose true and --verbose omitted' '
> +       git -c commit.verbose=true commit -F message &&
> +       test_line_count = 1 out
> +'

Why is this new test different (by using "-F message") from all other
new tests which simply use "--amend"? The answer is that it is
performing a "setup" action which should have been done in the "setup"
test just above. But, as noted, this extra setup is unnecessary, thus
also misleading and confusing for readers. Better would be to use the
minimal "setup" shown above (from [1]), and restore this test to use
"--amend" like all other tests.

More below...

> +test_expect_success 'commit.verbose true and --verbose' '
> +       git -c commit.verbose=true commit --amend --verbose &&
> +       test_line_count = 1 out
> +'
> +
> +test_expect_success 'commit.verbose true and -v -v' '
> +       git -c commit.verbose=true commit --amend -v -v &&
> +       test_line_count = 2 out
> +'
> [...large number of almost identical tests omitted...]
> +
> +test_expect_success 'commit.verbose=-2 and --no-verbose' '
> +       git -c commit.verbose=-2 commit --amend --no-verbose &&
> +       test_line_count = 0 out
> +'
> +
> +test_expect_success 'commit.verbose=-1 and --no-verbose' '
> +       git -c commit.verbose=-1 commit --amend --no-verbose &&
> +       test_line_count = 0 out
> +'
> +
> +test_expect_success 'commit.verbose=0 and --no-verbose' '
> +       git -c commit.verbose=0 commit --amend --no-verbose &&
> +       test_line_count = 0 out
> +'
> +
> +test_expect_success 'commit.verbose=1 and --no-verbose' '
> +       git -c commit.verbose=1 commit --amend --no-verbose &&
> +       test_line_count = 0 out
> +'

The fact that the 32 new tests are nearly identical suggests strongly
that the testing should instead either be table-driven or be done via
for-loops to systematically cover all cases. Not only would either of
these approaches be easier to digest, but they would make it easy to
tell at a glance if any cases were missing. See [2] for an example of
how the tests can be table-driven, and see the bottom of [3] for an
example of using for-loops to test systematically (though you'd need
to use nested for-loops rather than just the one in the example).

I'm leaning toward systematic testing via nested for-loops as the more
suitable of the two approach for this particular application.

[1]: http://article.gmane.org/gmane.comp.version-control.git/290000
[2]: http://article.gmane.org/gmane.comp.version-control.git/290344
[3]: http://article.gmane.org/gmane.comp.version-control.git/289860

Re: [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs

[Eric Sunshine]

On Sun, Apr 3, 2016 at 8:02 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Make the fake "editor" store output of grep in a file so that we can
>> see how many diffs were contained in the message and use them in
>> individual tests where ever it is required. Also use write_script()
>> to create the fake "editor".
>>
>> A subsequent commit will introduce scenarios where it is important to be
>> able to exactly determine how many diffs were present.
>
> These two sentences are backward. The "subsequent commit" bit is
> justification for why you are making the "editor" store the output,
> thus it belongs with the first paragraph. The bit about write_script()
> is just a minor aside which can go in its own paragraph.
>
> I think it's also important to explain that you're changing the
> behavior of write_script() so that it always succeeds, regardless of

s/write_script()/the fake "editor"/

> whether grep found diff headers or not, and to give the reason for
> making this change ("so that you don't have to use 'test_must_fail'
> for cases when no diff headers are expected and can instead easily use
> 'test_line_count = 0'").

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

[Pranit Bauva]

On Mon, Apr 4, 2016 at 2:30 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
>> @@ -7,7 +7,7 @@ test_description='our own option parser'
>>
>>  . ./test-lib.sh
>>
>> -cat > expect << EOF
>> +cat >expect <<EOF
>>  usage: test-parse-options <options>
>>      --yes                 get a boolean
>
> It would be better to use <<\EOF for this one to make it clear that no
> interpolation is desired in the heredoc.
>
>> @@ -156,7 +156,7 @@ test_expect_success 'OPT_MAGNITUDE() 3giga' '
>>         check magnitude: 3221225472 -m 3g
>>  '
>>
>> -cat > expect << EOF
>> +cat >expect <<EOF
>
> Ditto: <<\EOF
>
> Same applies to all similar heredocs in subsequent tests where
> interpolation is not desired.
>
>>  boolean: 2
>>  integer: 1729
>>  magnitude: 16384
>> @@ -310,12 +310,12 @@ arg 00: --quux
>>  EOF
>>
>>  test_expect_success 'keep some options as arguments' '
>> -       test-parse-options --quux > output 2> output.err &&
>> +       test-parse-options --quux >output 2>output.err &&
>>         test_must_be_empty output.err &&
>> -        test_cmp expect output
>> +       test_cmp expect output
>
> Okay, this is a whitespace change (spaces -> tab).
>
>>  '
>> @@ -460,7 +460,7 @@ test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
>> -cat >>expect <<'EOF'
>> +cat >>expect <<EOF
>
> This is not a desirable change. This heredoc does not require
> interpolation, so you don't want to turn it into a form which does
> interpolate. For style consistency, therefore, you should change 'EOF'
> to \EOF.
>
>>  list: foo
>>  list: bar
>>  list: baz

Okay I will do the change. I was previously unaware about the use of
'\' before EOF. I googled it now. But I am still confused about its
use in this scenario. Upto what I understood, it is used where you
want to expand a variable, substitute a command, arithmethic
expansion. The use of '\' in the tests I have changed in v12 wrt 11 is
understood by me as you want to remove the use of escape sequences
which is justified. But this seems a bit vague. Is it some convention
in git?

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

[Eric Sunshine]

On Mon, Apr 4, 2016 at 8:45 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Okay I will do the change. I was previously unaware about the use of
> '\' before EOF. I googled it now. But I am still confused about its
> use in this scenario. Upto what I understood, it is used where you
> want to expand a variable, substitute a command, arithmethic
> expansion. The use of '\' in the tests I have changed in v12 wrt 11 is
> understood by me as you want to remove the use of escape sequences
> which is justified. But this seems a bit vague. Is it some convention
> in git?

Both 'EOF' and \EOF suppress interpolation and other transformations
in the heredoc content which would otherwise occur with plain EOF. The
'EOF' form is well documented; \EOF not so much, but is used heavily
in git test scripts. So:

    x=flormp
    echo <<EOF
    Hello, $x
    EOF

prints "Hello, flormp", whereas:

    echo <<\EOF
    Hello, $x
    EOF

prints "Hello, $x".

While test scripts sometimes use \EOF to explicitly suppress variable
expansion, it's also quite common to use it even when there is nothing
which could be expanded in the heredoc content, in which case it
signals to the reader that the author doesn't expect the content to
undergo expansion or interpolation. It's also a bit of future-proofing
in case some later change to the heredoc content inserts something
which might otherwise be expanded.

Re: [PATCH v12 5/5] commit: add a commit.verbose config variable

[Eric Sunshine]

On Sun, Apr 3, 2016 at 8:58 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> The fact that the 32 new tests are nearly identical suggests strongly
> that the testing should instead either be table-driven or be done via
> for-loops to systematically cover all cases. Not only would either of
> these approaches be easier to digest, but they would make it easy to
> tell at a glance if any cases were missing. See [2] for an example of
> how the tests can be table-driven, and see the bottom of [3] for an
> example of using for-loops to test systematically (though you'd need
> to use nested for-loops rather than just the one in the example).
>
> I'm leaning toward systematic testing via nested for-loops as the more
> suitable of the two approach for this particular application.

By the way, while this would be a nice change, it doesn't necessarily
have to be part of this series, and could be done as a follow-up by
you or someone else.

(The other changes suggested in the same review, however, ought to be
fixed in this series; in particular, simplifying the "setup" test and
making the first test after "setup" consistent with the remaining
tests.)

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

[Pranit Bauva]

On Mon, Apr 4, 2016 at 11:00 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Mon, Apr 4, 2016 at 8:45 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Okay I will do the change. I was previously unaware about the use of
>> '\' before EOF. I googled it now. But I am still confused about its
>> use in this scenario. Upto what I understood, it is used where you
>> want to expand a variable, substitute a command, arithmethic
>> expansion. The use of '\' in the tests I have changed in v12 wrt 11 is
>> understood by me as you want to remove the use of escape sequences
>> which is justified. But this seems a bit vague. Is it some convention
>> in git?
>
> Both 'EOF' and \EOF suppress interpolation and other transformations
> in the heredoc content which would otherwise occur with plain EOF. The
> 'EOF' form is well documented; \EOF not so much, but is used heavily
> in git test scripts. So:
>
>     x=flormp
>     echo <<EOF
>     Hello, $x
>     EOF
>
> prints "Hello, flormp", whereas:
>
>     echo <<\EOF
>     Hello, $x
>     EOF
>
> prints "Hello, $x".
>
> While test scripts sometimes use \EOF to explicitly suppress variable
> expansion, it's also quite common to use it even when there is nothing
> which could be expanded in the heredoc content, in which case it
> signals to the reader that the author doesn't expect the content to
> undergo expansion or interpolation. It's also a bit of future-proofing
> in case some later change to the heredoc content inserts something
> which might otherwise be expanded.

Thanks for taking out your time to explain this clearly. I will do the
changes in the tests as suggested by your review. :)

Re: [PATCH v12 2/5] test-parse-options: print quiet as integer

[Pranit Bauva]

[+cc:Duy Nguyen, Jonathan Nieder]

On Mon, Apr 4, 2016 at 3:00 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>> and not boolean and thus it is more appropriate to print it as integer
>> to avoid confusion.
>
> I can buy this line of reasoning, however, it would be even easier to
> sell the change if you cited an existing client (a git command) which
> actually respects multiple quiet levels. Are there any?

I investigated into this. But I was unable to find any git commit
which actually respects mulitple quiet levels. I first did a 'git grep
OPT__QUIET' to find the commands which use this. Then I went through
the documentation which covers it. None of them have any such mention
of multiple quiet levels. But still I dug further and and went through
all the individual source files. I followed the corresponding C source
code for the header file included and also searched there for any
trace of quiet. But I still didn't find any such use of multiple quiet
levels. I have found that the commit id 212c0a6f (Duy Ngyuyen; 7 Dec,
2013; parse-options: remove OPT__BOOLEAN). Maybe he has something to
say as to why this was introduced and OPT__QUIET which previously used
OPT__BOOLEAN, now uses OPT_COUNTUP rather than OPT_BOOL. This commit
In fact git-repack command has quiet but this is not mentioned in the
documentation. If someone could include this it in the documentation.
I would do it but I am not quite familiar with git-repack and haven't
really used it anytime.

> More importantly, though, this change implies that you should also add
> tests to ensure that the quiet level is indeed incremented with each
> --quiet, just as "-vv" and "--verbose --verbose" are already tested.
> You might be able to include such new tests directly in this patch as
> long as the commit message is clear about it, or add them in a
> separate patch.

I will include the tests for multiple level of quiet in the patch.

> By the way, I don't see any tests to ensure that --no-verbose and
> --no-quiet reset those respective values to 0. A separate patch which
> adds such tests would be nice (unless such tests already exist and I
> merely missed them).
There are no tests to ensure that --no-verbose and --no-quiet reset
those respective values to 0 just before this patch. But I have
covered the --no-verbose tests in the upcoming patch 3/5. I will
include the tests for --no-quiet in this patch.

Re: [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

On Mon, Apr 4, 2016 at 4:40 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> The reason to make it respect "unspecified" values is to give the
>> ability to differentiate whether `--option` or `--no-option` was
>> specified at all. "unspecified" values should be in the form of negative
>> values. If initial value is set to negative and `--option` specified
>> then it will reflect the number of occurrences (counting done from 0),
>> if `--no-option` is specified then it will reflect 0 and if nothing at
>> all is given then it will retain its negative value.
>
> Thanks, this rewrite does a better job of explaining the aim of the
> change and how a client can take advantage of it. However, with my
> "first-time reader" hat on, I still have some trouble digesting it as
> a coherent whole. I wonder if a rewrite like this would help?
>
>     OPT_COUNTUP() merely increments the counter upon --option, and
>     resets it to 0 upon --no-option, which means that there is no
>     "unspecified" value with which a client can initialize the
>     counter to determine whether or not --[no-]option was seen at
>     all.
>
>     Make OPT_COUNTUP() treat any negative number as an "unspecified"
>     value to address this shortcoming. In particular, if a client
>     initializes the counter to -1, then if it is still -1 after
>     parse_options(), then neither --option nor --no-option was seen;
>     if it is 0, then --no-option was seen last, and if it is 1 or
>     greater, than --option was seen last.
>
>> This change will not affect existing users of COUNTUP, because they all
>> use the initial value of 0 (or more).
>
>     "This change does not affect behavior of existing clients of..."
>

Sure I could do the change.

>> Note that builtin/clean.c initializes the variable used with
>> OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
>> to either 0 or 1 by reading the configuration before the code calls
>> parse_options(), i.e. as far as parse_options() is concerned, the
>> initial value of the variable is not negative.
>>
>> To test this behavior "verbose" is set to "unspecified" while quiet is
>> set to 0 which will test the new behavior with all sets of values.
>
> I think you need to mention here that you're talking about test-parse-options.c
> (and indirectly t0040) since it's otherwise too easy for the reader to
> think that this paragraph is a continuation of the discussion about
> OPT_COUNTUP()'s new behavior and how it won't impact existing tests,
> rather than a new topic of its own (testing the behavior). Maybe say
> something like this:
>
>     To test the new behavior, augment the initial "verbose" setting
>     of test-parse-options.c to be unspecified...
>
> and then go on to say that, because "quiet" is still initialized to 0,
> you have complete coverage. An alternative would be to split off the
> new testing into its own patch, which would make this patch (which is
> the real meat of the change) less noisy.

I do like including test-parse-options.c in commit message. My main
motive behind including the test with this patch was to show the
"first-time" reader how to use the changes introduced in this patch.
This would also set a complete picture of this commit. And I kind of
believe it is much effort for the reader to find the commit whose
parent will be this (if it exists at all, as the reader won't know
about it) which will give a kind of demonstration to utilizing this
change.

>
> I actually expected you to add new functionality to
> test-parse-options.c specifically to test OPT_COUNTUP() directly
> rather than indirectly through --verbose and --quiet, however, I think
> I can be sold on the approach you took for a couple reasons. First,
> you have a genuine use-case for an "unspecified" --verbose value, so
> changing test-parse-options.c's --verbose to start at -1 tests what
> you ultimately care about. Second, since you retained 0-initialization
> of --quiet, that case of OPT_COUNTUP() is still being tested.
>
> What I find a bit disturbing about this approach is that you are
> getting "full coverage" only because of current *implementation*, not
> because you are explicitly testing for *expected* behavior. That is,
> you get that coverage only while both OPT__VERBOSE() and OPT__QUIET()
> are built atop OPT_COUNTUP(); if OPT__QUIET() is ever rewritten so it
> no longer uses OPT_COUNTUP(), then the tests silently lose full
> coverage. However, I may be over-worrying about the situation...

The main reason as I mentioned above was to give a demonstration of
how to utilize the change introduced.

>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
>> @@ -144,8 +144,12 @@ There are some macros to easily define options:
>>  `OPT_COUNTUP(short, long, &int_var, description)`::
>>         Introduce a count-up option.
>> -       `int_var` is incremented on each use of `--option`, and
>> -       reset to zero with `--no-option`.
>> +       Each use of `--option` increments `int_var`, starting from zero
>> +       (even if initially negative), and `--no-option` resets it to
>> +       zero. To determine if `--option` or `--no-option` was set at
>
> s/was set/was encountered/
>
>> +       all, set `int_var` to a negative value, and if it is still
>
> s/set `int_var`/initialize `int_var`/
>
>> +       negative after parse_options(), then neither `--option` nor
>> +       `--no-option` was seen.
>> diff --git a/parse-options.c b/parse-options.c
>> @@ -110,6 +110,8 @@ static int get_value(struct parse_opt_ctx_t *p,
>>         case OPTION_COUNTUP:
>> +               if (*(int *)opt->value < 0)
>> +                       *(int *)opt->value = 0;
>>                 *(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
>
> This is nicer.
>
>>                 return 0;
>> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
>> @@ -454,6 +454,25 @@ dry run: no
>> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
>> +       test-parse-options --no-verbose >output 2>output.err &&
>> +       test_must_be_empty output.err &&
>> +       test_cmp expect output
>> +'
>
> If you take the advice of my 2/5 review and add new tests (in a new
> patch) which test --no-verbose and --no-quiet, then I think this new
> test here can just go away since the case it cares about will already
> be covered.

Adding a new patch between 2/5 and 3/5 would be a better choice.

Re: [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

On Mon, Apr 4, 2016 at 5:32 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Make the fake "editor" store output of grep in a file so that we can
>> see how many diffs were contained in the message and use them in
>> individual tests where ever it is required. Also use write_script()
>> to create the fake "editor".
>>
>> A subsequent commit will introduce scenarios where it is important to be
>> able to exactly determine how many diffs were present.
>
> These two sentences are backward. The "subsequent commit" bit is
> justification for why you are making the "editor" store the output,
> thus it belongs with the first paragraph. The bit about write_script()
> is just a minor aside which can go in its own paragraph.
>
> I think it's also important to explain that you're changing the
> behavior of write_script() so that it always succeeds, regardless of
> whether grep found diff headers or not, and to give the reason for
> making this change ("so that you don't have to use 'test_must_fail'
> for cases when no diff headers are expected and can instead easily use
> 'test_line_count = 0'").
>
> The patch itself looks fine and is easy enough to read.

I will include some more explanation as you suggest.

>
>> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
>> index 2ddf28c..0f28a86 100755
>> --- a/t/t7507-commit-verbose.sh
>> +++ b/t/t7507-commit-verbose.sh
>> @@ -3,11 +3,10 @@
>>  test_description='verbose commit template'
>>  . ./test-lib.sh
>>
>> -cat >check-for-diff <<EOF
>> -#!$SHELL_PATH
>> -exec grep '^diff --git' "\$1"
>> +write_script "check-for-diff" <<\EOF &&
>> +grep '^diff --git' "$1" >out
>> +exit 0
>>  EOF
>> -chmod +x check-for-diff
>>  test_set_editor "$PWD/check-for-diff"
>>
>>  cat >message <<'EOF'
>> @@ -23,7 +22,8 @@ test_expect_success 'setup' '
>>  '
>>
>>  test_expect_success 'initial commit shows verbose diff' '
>> -       git commit --amend -v
>> +       git commit --amend -v &&
>> +       test_line_count = 1 out
>>  '
>>
>>  test_expect_success 'second commit' '
>> @@ -39,13 +39,15 @@ check_message() {
>>
>>  test_expect_success 'verbose diff is stripped out' '
>>         git commit --amend -v &&
>> -       check_message message
>> +       check_message message &&
>> +       test_line_count = 1 out
>>  '
>>
>>  test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
>>         git config diff.mnemonicprefix true &&
>>         git commit --amend -v &&
>> -       check_message message
>> +       check_message message &&
>> +       test_line_count = 1 out
>>  '

Re: [PATCH v12 5/5] commit: add a commit.verbose config variable

[Pranit Bauva]

On Tue, Apr 5, 2016 at 4:59 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Sun, Apr 3, 2016 at 8:58 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> The fact that the 32 new tests are nearly identical suggests strongly
>> that the testing should instead either be table-driven or be done via
>> for-loops to systematically cover all cases. Not only would either of
>> these approaches be easier to digest, but they would make it easy to
>> tell at a glance if any cases were missing. See [2] for an example of
>> how the tests can be table-driven, and see the bottom of [3] for an
>> example of using for-loops to test systematically (though you'd need
>> to use nested for-loops rather than just the one in the example).
>>
>> I'm leaning toward systematic testing via nested for-loops as the more
>> suitable of the two approach for this particular application.
>
I hadn't thought of this before. I also believe using for-loops will
make it more clear, crisp and will avoid the effort of going through
the whole patch to find out if some test is missing.

> By the way, while this would be a nice change, it doesn't necessarily
> have to be part of this series, and could be done as a follow-up by
> you or someone else.
>
> (The other changes suggested in the same review, however, ought to be
> fixed in this series; in particular, simplifying the "setup" test and
> making the first test after "setup" consistent with the remaining
> tests.)

I will include it this series only as it will be a bit easier for me
to keep a track of the previous reviews.

Re: [PATCH v12 2/5] test-parse-options: print quiet as integer

[Eric Sunshine]

On Tue, Apr 5, 2016 at 11:39 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Mon, Apr 4, 2016 at 3:00 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>>> and not boolean and thus it is more appropriate to print it as integer
>>> to avoid confusion.
>>
>> I can buy this line of reasoning, however, it would be even easier to
>> sell the change if you cited an existing client (a git command) which
>> actually respects multiple quiet levels. Are there any?
>
> I investigated into this. But I was unable to find any git commit
> which actually respects mulitple quiet levels. I first did a 'git grep
> OPT__QUIET' to find the commands which use this. Then I went through
> the documentation which covers it. None of them have any such mention
> of multiple quiet levels. But still I dug further and and went through
> all the individual source files. I followed the corresponding C source
> code for the header file included and also searched there for any
> trace of quiet. But I still didn't find any such use of multiple quiet
> levels. I have found that the commit id 212c0a6f (Duy Ngyuyen; 7 Dec,
> 2013; parse-options: remove OPT__BOOLEAN). Maybe he has something to
> say as to why this was introduced and OPT__QUIET which previously used
> OPT__BOOLEAN, now uses OPT_COUNTUP rather than OPT_BOOL. This commit
> In fact git-repack command has quiet but this is not mentioned in the
> documentation. If someone could include this it in the documentation.
> I would do it but I am not quite familiar with git-repack and haven't
> really used it anytime.

I didn't find any existing Git command recognizing multiple quiet
levels either, however, I think I can still buy the change considering
that there is existing precedent in other Unix commands.

Re: [PATCH v12 2/5] test-parse-options: print quiet as integer

[Duy Nguyen]

On Tue, Apr 5, 2016 at 10:39 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> [+cc:Duy Nguyen, Jonathan Nieder]
>
> On Mon, Apr 4, 2016 at 3:00 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>>> and not boolean and thus it is more appropriate to print it as integer
>>> to avoid confusion.
>>
>> I can buy this line of reasoning, however, it would be even easier to
>> sell the change if you cited an existing client (a git command) which
>> actually respects multiple quiet levels. Are there any?
>
> I investigated into this. But I was unable to find any git commit
> which actually respects mulitple quiet levels. I first did a 'git grep
> OPT__QUIET' to find the commands which use this. Then I went through
> the documentation which covers it. None of them have any such mention
> of multiple quiet levels. But still I dug further and and went through
> all the individual source files. I followed the corresponding C source
> code for the header file included and also searched there for any
> trace of quiet. But I still didn't find any such use of multiple quiet
> levels. I have found that the commit id 212c0a6f (Duy Ngyuyen; 7 Dec,
> 2013; parse-options: remove OPT__BOOLEAN). Maybe he has something to
> say as to why this was introduced and OPT__QUIET which previously used
> OPT__BOOLEAN, now uses OPT_COUNTUP rather than OPT_BOOL.

I don't have much to say because my commit is a harmless conversion :)
OPT_BOOLEAN _is_ OPT_COUNTUP with a misleading name, see b04ba2b
(parse-options: deprecate OPT_BOOLEAN - 2011-09-27). If you dig
further back, both OPT_VERBOSE and OPT_QUIET are introduced at the
same time in 0ce865b (Add shortcuts for very often used options. -
2007-10-14) and they both are defined with OPT_BOOLEAN. I guess it was
just an oversight that OPT_QUIET is defined as OPT_BOOLEAN instead of
OPT_BOOL.
-- 
Duy

Re: [PATCH v12 2/5] test-parse-options: print quiet as integer

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>> and not boolean and thus it is more appropriate to print it as integer
>> to avoid confusion.
>
> I can buy this line of reasoning, however, it would be even easier to
> sell the change if you cited an existing client (a git command) which
> actually respects multiple quiet levels. Are there any?

This is the only one I found in Documentation/

    -q::
    --quiet::
            Make 'git svn' less verbose. Specify a second time to make it
            even less verbose.

It probably is not a good idea to use OPT__QUIET() and try to do
multiple classes of quietness in the longer term anyway.

New work should be done to improve OPT_VERBOSITY() that already can
do "even more verbose" and "even more quiet" with a single variable;
currently there is no way to ask "has any verbosity ever been given
from the command line?", and we may want to support that.

[PATCH v13 1/6] t0040-test-parse-options.sh: fix style issues

[Pranit Bauva]

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
Changes wrt previous version (v12):
 - Use '\' when interpolation isn't required
---
 t/t0040-parse-options.sh | 76 ++++++++++++++++++++++++------------------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 9be6411..477fcff 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -7,7 +7,7 @@ test_description='our own option parser'
 
 . ./test-lib.sh
 
-cat > expect << EOF
+cat >expect <<\EOF
 usage: test-parse-options <options>
 
     --yes                 get a boolean
@@ -49,14 +49,14 @@ Standard options
 EOF
 
 test_expect_success 'test help' '
-	test_must_fail test-parse-options -h > output 2> output.err &&
+	test_must_fail test-parse-options -h >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_i18ncmp expect output
 '
 
 mv expect expect.err
 
-cat >expect.template <<EOF
+cat >expect.template <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -156,7 +156,7 @@ test_expect_success 'OPT_MAGNITUDE() 3giga' '
 	check magnitude: 3221225472 -m 3g
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -176,7 +176,7 @@ test_expect_success 'short options' '
 	test_must_be_empty output.err
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -204,7 +204,7 @@ test_expect_success 'missing required value' '
 	test_expect_code 129 test-parse-options --file
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 1
 integer: 13
 magnitude: 0
@@ -222,12 +222,12 @@ EOF
 
 test_expect_success 'intermingled arguments' '
 	test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
-		> output 2> output.err &&
+		>output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 2
 magnitude: 0
@@ -241,13 +241,13 @@ file: (not set)
 EOF
 
 test_expect_success 'unambiguously abbreviated option' '
-	test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
+	test-parse-options --int 2 --boolean --no-bo >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'unambiguously abbreviated option with "="' '
-	test-parse-options --int=2 > output 2> output.err &&
+	test-parse-options --int=2 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
@@ -256,7 +256,7 @@ test_expect_success 'ambiguously abbreviated option' '
 	test_expect_code 129 test-parse-options --strin 123
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -270,32 +270,32 @@ file: (not set)
 EOF
 
 test_expect_success 'non ambiguous option (after two options it abbreviates)' '
-	test-parse-options --st 123 > output 2> output.err &&
+	test-parse-options --st 123 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > typo.err << EOF
-error: did you mean \`--boolean\` (with two dashes ?)
+cat >typo.err <<\EOF
+error: did you mean `--boolean` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -boolean > output 2> output.err &&
+	test_must_fail test-parse-options -boolean >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > typo.err << EOF
-error: did you mean \`--ambiguous\` (with two dashes ?)
+cat >typo.err <<\EOF
+error: did you mean `--ambiguous` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -ambiguous > output 2> output.err &&
+	test_must_fail test-parse-options -ambiguous >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -310,12 +310,12 @@ arg 00: --quux
 EOF
 
 test_expect_success 'keep some options as arguments' '
-	test-parse-options --quux > output 2> output.err &&
+	test-parse-options --quux >output 2>output.err &&
 	test_must_be_empty output.err &&
-        test_cmp expect output
+	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -331,12 +331,12 @@ EOF
 
 test_expect_success 'OPT_DATE() works' '
 	test-parse-options -t "1970-01-01 00:00:01 +0000" \
-		foo -q > output 2> output.err &&
+		foo -q >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 Callback: "four", 0
 boolean: 5
 integer: 4
@@ -351,22 +351,22 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_CALLBACK() and OPT_BIT() work' '
-	test-parse-options --length=four -b -4 > output 2> output.err &&
+	test-parse-options --length=four -b -4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 Callback: "not set", 1
 EOF
 
 test_expect_success 'OPT_CALLBACK() and callback errors work' '
-	test_must_fail test-parse-options --no-length > output 2> output.err &&
+	test_must_fail test-parse-options --no-length >output 2>output.err &&
 	test_i18ncmp expect output &&
 	test_i18ncmp expect.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 1
 integer: 23
 magnitude: 0
@@ -380,18 +380,18 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --no-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --no-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --neg-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 6
 integer: 0
 magnitude: 0
@@ -405,24 +405,24 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() works' '
-	test-parse-options -bb --or4 > output 2> output.err &&
+	test-parse-options -bb --or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() works' '
-	test-parse-options -bb --no-neg-or4 > output 2> output.err &&
+	test-parse-options -bb --no-neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
-	test-parse-options + + + + + + > output 2> output.err &&
+	test-parse-options + + + + + + >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 12345
 magnitude: 0
@@ -436,12 +436,12 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_NUMBER_CALLBACK() works' '
-	test-parse-options -12345 > output 2> output.err &&
+	test-parse-options -12345 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat >expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -460,7 +460,7 @@ test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test_cmp expect output
 '
 
-cat >>expect <<'EOF'
+cat >>expect <<\EOF
 list: foo
 list: bar
 list: baz

--
https://github.com/git/git/pull/218

[PATCH v13 6/6] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:
 - [v12] $gmane/288820
 - [v11] $gmane/288820
 - [v10] $gmane/288820
 - [v9] $gmane/288820
 - [v8] $gmane/288820
 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

   Note: One might think some tests are extra but I think that it will
   be better to include them as they "complete the continuity" thus
   generalising the series which will make the patch even more clearer.

Changes wrt v12:
 - Change the setup test as suggested by Eric.
 - Use for loops for systematic testing. I have avoided nested-for loops
   or using a function to test because I believe it will just add to the
   complexity rather than simplifying it. Just by using for loops the
   tests look quite systematic and easy to digest.
---
 Documentation/config.txt     |  4 ++++
 Documentation/git-commit.txt |  3 ++-
 builtin/commit.c             | 14 ++++++++++-
 t/t7507-commit-verbose.sh    | 56 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..96e6190 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1354,6 +1356,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 			     builtin_status_usage, 0);
 	finalize_colopts(&s.colopts, -1);
 	finalize_deferred_config(&s);
+	if (verbose == -1)
+		verbose = 0;
 
 	handle_untracked_files_arg(&s);
 	if (show_ignored_in_status)
@@ -1505,6 +1509,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1663,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+	if (verbose == -1)
+		verbose = (config_verbose < 0) ? 0 : config_verbose;
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 0f28a86..00e0c3d 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -98,4 +98,60 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'setup -v -v' '
+	echo dirty >file
+'
+
+for i in true 1
+do
+	test_expect_success "commit.verbose=$i and --verbose omitted" "
+		git -c commit.verbose=$i commit --amend &&
+		test_line_count = 1 out
+	"
+done
+
+for i in false -2 -1 0
+do
+	test_expect_success "commit.verbose=$i and --verbose omitted" "
+		git -c commit.verbose=$i commit --amend &&
+		test_line_count = 0 out
+	"
+done
+
+for i in 2 3
+do
+	test_expect_success "commit.verbose=$i and --verbose omitted" "
+		git -c commit.verbose=$i commit --amend &&
+		test_line_count = 2 out
+	"
+done
+
+for i in true false -2 -1 0 1 2 3
+do
+	test_expect_success "commit.verbose=$i and --verbose" "
+		git -c commit.verbose=$i commit --amend --verbose &&
+		test_line_count = 1 out
+	"
+
+	test_expect_success "commit.verbose=$i and --no-verbose" "
+		git -c commit.verbose=$i commit --amend --no-verbose &&
+		test_line_count = 0 out
+	"
+
+	test_expect_success "commit.verbose=$i and -v -v" "
+		git -c commit.verbose=$i commit --amend -v -v &&
+		test_line_count = 2 out
+	"
+done
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
+test_expect_success 'status does not verbose without --verbose' '
+	git status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/218

[PATCH v13 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

Make the fake "editor" store output of grep in a file so that we can
see how many diffs were contained in the message and use them in
individual tests where ever it is required. A subsequent commit will
introduce scenarios where it is important to be able to exactly
determine how many diffs were present.

Also use write_script() to create the fake "editor".

The fake "editor" is always made to succeed regardless of whether grep
found diff headers or not so that we don't have to use 'test_must_fail'
for which 'test_line_count = 0' is an easy substitute.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
Previous version of this patch:
 - [v12] : $gmane/288820
 - [v11] : $gmane/288820
 - [v10]: $gmane/288820

Changes this version wrt previous one:
Change the commit message as suggested by Eric
---
 t/t7507-commit-verbose.sh | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..0f28a86 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -3,11 +3,10 @@
 test_description='verbose commit template'
 . ./test-lib.sh
 
-cat >check-for-diff <<EOF
-#!$SHELL_PATH
-exec grep '^diff --git' "\$1"
+write_script "check-for-diff" <<\EOF &&
+grep '^diff --git' "$1" >out
+exit 0
 EOF
-chmod +x check-for-diff
 test_set_editor "$PWD/check-for-diff"
 
 cat >message <<'EOF'
@@ -23,7 +22,8 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'initial commit shows verbose diff' '
-	git commit --amend -v
+	git commit --amend -v &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'second commit' '
@@ -39,13 +39,15 @@ check_message() {
 
 test_expect_success 'verbose diff is stripped out' '
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
 	git config diff.mnemonicprefix true &&
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 cat >diff <<'EOF'

--
https://github.com/git/git/pull/218

[PATCH v13 2/6] test-parse-options: print quiet as integer

[Pranit Bauva]

Current implementation of parse-options.c treats OPT__QUIET() as integer
and not boolean and thus it is more appropriate to print it as integer
to avoid confusion.

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
 t/t0040-parse-options.sh | 26 +++++++++++++-------------
 test-parse-options.c     |  2 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 477fcff..450da45 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -64,7 +64,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -164,7 +164,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 2
-quiet: no
+quiet: 0
 dry run: yes
 file: prefix/my.file
 EOF
@@ -184,7 +184,7 @@ timestamp: 0
 string: 321
 abbrev: 10
 verbose: 2
-quiet: no
+quiet: 0
 dry run: no
 file: prefix/fi.le
 EOF
@@ -212,7 +212,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: a1
@@ -235,7 +235,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -264,7 +264,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -303,7 +303,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: --quux
@@ -323,7 +323,7 @@ timestamp: 1
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: yes
+quiet: 1
 dry run: no
 file: (not set)
 arg 00: foo
@@ -345,7 +345,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -374,7 +374,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -399,7 +399,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -430,7 +430,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -449,7 +449,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
diff --git a/test-parse-options.c b/test-parse-options.c
index 2c8c8f1..86afa98 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -90,7 +90,7 @@ int main(int argc, char **argv)
 	printf("string: %s\n", string ? string : "(not set)");
 	printf("abbrev: %d\n", abbrev);
 	printf("verbose: %d\n", verbose);
-	printf("quiet: %s\n", quiet ? "yes" : "no");
+	printf("quiet: %d\n", quiet);
 	printf("dry run: %s\n", dry_run ? "yes" : "no");
 	printf("file: %s\n", file ? file : "(not set)");
 

--
https://github.com/git/git/pull/218

[PATCH v13 3/6] t0040-parse-options: improve test coverage

[Pranit Bauva]

Include tests to check for multiple levels of quiet and to check if the
'--no-quiet' option sets it to 0.

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
 t/t0040-parse-options.sh | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 450da45..c913d1c 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -476,4 +476,41 @@ test_expect_success '--no-list resets list' '
 	test_cmp expect output
 '
 
+cat >expect <<\EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: 0
+quiet: 3
+dry run: no
+file: (not set)
+EOF
+
+test_expect_success 'multiple quiet levels' '
+	test-parse-options -q -q -q >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
+
+cat >expect <<\EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: 0
+quiet: 0
+dry run: no
+file: (not set)
+EOF
+
+test_expect_success '--no-quiet sets quiet to 0' '
+	test-parse-options --no-quiet >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
 test_done

--
https://github.com/git/git/pull/218

[PATCH v13 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.

Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; If it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.

This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).

Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.

To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v11] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v10] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v9] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes wrt previous version (v12):
 - Use bits of commit message provided by Eric Sunshine.

Please Note: The diff might seem improper especially the part where I
have introduced some continuous lines but this is a logical error by git
diff (nothing could be done about it) and thus the changes will be
clearly visible with the original file itself.
---
 Documentation/technical/api-parse-options.txt |  8 ++++--
 parse-options.c                               |  2 ++
 t/t0040-parse-options.sh                      | 39 ++++++++++++++++++++-------
 test-parse-options.c                          |  3 ++-
 4 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..8908bf7 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,12 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	Each use of `--option` increments `int_var`, starting from zero
+	(even if initially negative), and `--no-option` resets it to
+	zero. To determine if `--option` or `--no-option` was set at
+	all, set `int_var` to a negative value, and if it is still
+	negative after parse_options(), then neither `--option` nor
+	`--no-option` was seen.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..312a85d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,6 +110,8 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
+		if (*(int *)opt->value < 0)
+			*(int *)opt->value = 0;
 		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
 		return 0;
 
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index c913d1c..efcd844 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -63,7 +63,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -211,7 +211,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -234,7 +234,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -263,7 +263,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -302,7 +302,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -322,7 +322,7 @@ magnitude: 0
 timestamp: 1
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 1
 dry run: no
 file: (not set)
@@ -344,7 +344,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -373,7 +373,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -398,7 +398,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -429,7 +429,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -454,6 +454,25 @@ dry run: no
 file: (not set)
 EOF
 
+test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
+	test-parse-options --no-verbose >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
+
+cat >expect <<EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: -1
+quiet: 0
+dry run: no
+file: (not set)
+EOF
+
 test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test-parse-options --no-ambig >output 2>output.err &&
 	test_must_be_empty output.err &&
diff --git a/test-parse-options.c b/test-parse-options.c
index 86afa98..f02c275 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -7,7 +7,8 @@ static int integer = 0;
 static unsigned long magnitude = 0;
 static unsigned long timestamp;
 static int abbrev = 7;
-static int verbose = 0, dry_run = 0, quiet = 0;
+static int verbose = -1; /* unspecified */
+static int dry_run = 0, quiet = 0;
 static char *string = NULL;
 static char *file = NULL;
 static int ambiguous;

--
https://github.com/git/git/pull/218

Re: [PATCH v13 6/6] commit: add a commit.verbose config variable

[Junio C Hamano]

Hmph, isn't this already in 'next', hence we cannot accept a
replacement patch?

Re: [PATCH v13 6/6] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Apr 13, 2016 at 2:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Hmph, isn't this already in 'next', hence we cannot accept a
> replacement patch?

Yes, this is already in 'next'. This was going to be merged in the
third cycle after 2.8 but on my request, you delayed it. So this is an
update on the patch. Is it that once a patch is in 'next', it cannot
be replaced with a new updated one? There are 5 other patches along
with this which are a requirement for this patch.

Re: [PATCH v13 2/6] test-parse-options: print quiet as integer

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> Current implementation of parse-options.c treats OPT__QUIET() as integer
> and not boolean and thus it is more appropriate to print it as integer
> to avoid confusion.

There is no "confusion" factor involved, as we do not use native
"boolean" type in our C code.  IIUC, the reason why we want to do
this is because we may want to see how it would affect the value of
the underlying variable to give multiple --quiet options from the
command line, which is a policy issue (i.e. we want to allow
commands to react to multiple quiet options differently), not an
implementation one (i.e. "current implementation happens to use
integer").

	We would want to see how multiple --quiet options affect the
	value of the underlying variable (we may want "--quiet --quiet"
	to still be 1, or we may want to see the value incremented
	to 2).  Show the value as integer to allow us to inspect it.

perhaps?

>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
>  t/t0040-parse-options.sh | 26 +++++++++++++-------------
>  test-parse-options.c     |  2 +-
>  2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> index 477fcff..450da45 100755
> --- a/t/t0040-parse-options.sh
> +++ b/t/t0040-parse-options.sh
> @@ -64,7 +64,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -164,7 +164,7 @@ timestamp: 0
>  string: 123
>  abbrev: 7
>  verbose: 2
> -quiet: no
> +quiet: 0
>  dry run: yes
>  file: prefix/my.file
>  EOF
> @@ -184,7 +184,7 @@ timestamp: 0
>  string: 321
>  abbrev: 10
>  verbose: 2
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: prefix/fi.le
>  EOF
> @@ -212,7 +212,7 @@ timestamp: 0
>  string: 123
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  arg 00: a1
> @@ -235,7 +235,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -264,7 +264,7 @@ timestamp: 0
>  string: 123
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -303,7 +303,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  arg 00: --quux
> @@ -323,7 +323,7 @@ timestamp: 1
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: yes
> +quiet: 1
>  dry run: no
>  file: (not set)
>  arg 00: foo
> @@ -345,7 +345,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -374,7 +374,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -399,7 +399,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -430,7 +430,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> @@ -449,7 +449,7 @@ timestamp: 0
>  string: (not set)
>  abbrev: 7
>  verbose: 0
> -quiet: no
> +quiet: 0
>  dry run: no
>  file: (not set)
>  EOF
> diff --git a/test-parse-options.c b/test-parse-options.c
> index 2c8c8f1..86afa98 100644
> --- a/test-parse-options.c
> +++ b/test-parse-options.c
> @@ -90,7 +90,7 @@ int main(int argc, char **argv)
>  	printf("string: %s\n", string ? string : "(not set)");
>  	printf("abbrev: %d\n", abbrev);
>  	printf("verbose: %d\n", verbose);
> -	printf("quiet: %s\n", quiet ? "yes" : "no");
> +	printf("quiet: %d\n", quiet);
>  	printf("dry run: %s\n", dry_run ? "yes" : "no");
>  	printf("file: %s\n", file ? file : "(not set)");
>  
>
> --
> https://github.com/git/git/pull/218

Re: [PATCH v13 6/6] commit: add a commit.verbose config variable

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Hmph, isn't this already in 'next', hence we cannot accept a
> replacement patch?

As a one-time measure, I'll revert the previous one

50f0d20d (commit: add a commit.verbose config variable, 2016-03-14)

out of 'next' and queue this one instead on 'pu'.

Re: [PATCH v13 2/6] test-parse-options: print quiet as integer

[Pranit Bauva]

On Wed, Apr 13, 2016 at 3:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Pranit Bauva <pranit.bauva@gmail.com> writes:
>
>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>> and not boolean and thus it is more appropriate to print it as integer
>> to avoid confusion.
>
> There is no "confusion" factor involved, as we do not use native
> "boolean" type in our C code.  IIUC, the reason why we want to do
> this is because we may want to see how it would affect the value of
> the underlying variable to give multiple --quiet options from the
> command line, which is a policy issue (i.e. we want to allow
> commands to react to multiple quiet options differently), not an
> implementation one (i.e. "current implementation happens to use
> integer").
>
>         We would want to see how multiple --quiet options affect the
>         value of the underlying variable (we may want "--quiet --quiet"
>         to still be 1, or we may want to see the value incremented
>         to 2).  Show the value as integer to allow us to inspect it.
>
> perhaps?

This commit message does look a lot better. I will re-roll this.
Should I just send an update of this patch or the whole series?

Re: [PATCH v13 6/6] commit: add a commit.verbose config variable

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Hmph, isn't this already in 'next', hence we cannot accept a
>> replacement patch?
>
> As a one-time measure, I'll revert the previous one
>
> 50f0d20d (commit: add a commit.verbose config variable, 2016-03-14)
>
> out of 'next' and queue this one instead on 'pu'.

I queued these 6 patches on 'master' and merged to 'pu', but it
seems the series breaks t0040, so in the meantime, I ejected the
whole thing.

Re: [PATCH v13 6/6] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Apr 13, 2016 at 3:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Hmph, isn't this already in 'next', hence we cannot accept a
>>> replacement patch?
>>
>> As a one-time measure, I'll revert the previous one
>>
>> 50f0d20d (commit: add a commit.verbose config variable, 2016-03-14)
>>
>> out of 'next' and queue this one instead on 'pu'.
>
> I queued these 6 patches on 'master' and merged to 'pu', but it
> seems the series breaks t0040, so in the meantime, I ejected the
> whole thing.

I forgot to update the newly introduced tests in this series for the
new behaviour. I will send an re-roll

[PATCH v14 2/6] test-parse-options: print quiet as integer

[Pranit Bauva]

We would want to see how multiple --quiet options affect the value of
the underlying variable (we may want "--quiet --quiet" to still be 1, or
we may want to see the value incremented to 2). Show the value as
integer to allow us to inspect it.

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
 t/t0040-parse-options.sh | 26 +++++++++++++-------------
 test-parse-options.c     |  2 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 477fcff..450da45 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -64,7 +64,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -164,7 +164,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 2
-quiet: no
+quiet: 0
 dry run: yes
 file: prefix/my.file
 EOF
@@ -184,7 +184,7 @@ timestamp: 0
 string: 321
 abbrev: 10
 verbose: 2
-quiet: no
+quiet: 0
 dry run: no
 file: prefix/fi.le
 EOF
@@ -212,7 +212,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: a1
@@ -235,7 +235,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -264,7 +264,7 @@ timestamp: 0
 string: 123
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -303,7 +303,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 arg 00: --quux
@@ -323,7 +323,7 @@ timestamp: 1
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: yes
+quiet: 1
 dry run: no
 file: (not set)
 arg 00: foo
@@ -345,7 +345,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -374,7 +374,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -399,7 +399,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -430,7 +430,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
@@ -449,7 +449,7 @@ timestamp: 0
 string: (not set)
 abbrev: 7
 verbose: 0
-quiet: no
+quiet: 0
 dry run: no
 file: (not set)
 EOF
diff --git a/test-parse-options.c b/test-parse-options.c
index 2c8c8f1..86afa98 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -90,7 +90,7 @@ int main(int argc, char **argv)
 	printf("string: %s\n", string ? string : "(not set)");
 	printf("abbrev: %d\n", abbrev);
 	printf("verbose: %d\n", verbose);
-	printf("quiet: %s\n", quiet ? "yes" : "no");
+	printf("quiet: %d\n", quiet);
 	printf("dry run: %s\n", dry_run ? "yes" : "no");
 	printf("file: %s\n", file ? file : "(not set)");
 

--
https://github.com/git/git/pull/218

[PATCH v14 3/6] t0040-parse-options: improve test coverage

[Pranit Bauva]

Include tests to check for multiple levels of quiet and to check if the
'--no-quiet' option sets it to 0.

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
 t/t0040-parse-options.sh | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 450da45..c913d1c 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -476,4 +476,41 @@ test_expect_success '--no-list resets list' '
 	test_cmp expect output
 '
 
+cat >expect <<\EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: 0
+quiet: 3
+dry run: no
+file: (not set)
+EOF
+
+test_expect_success 'multiple quiet levels' '
+	test-parse-options -q -q -q >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
+
+cat >expect <<\EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: 0
+quiet: 0
+dry run: no
+file: (not set)
+EOF
+
+test_expect_success '--no-quiet sets quiet to 0' '
+	test-parse-options --no-quiet >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
 test_done

--
https://github.com/git/git/pull/218

[PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues

[Pranit Bauva]

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
Changes wrt previous version (v12):
 - Use '\' when interpolation isn't required
---
 t/t0040-parse-options.sh | 76 ++++++++++++++++++++++++------------------------
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 9be6411..477fcff 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -7,7 +7,7 @@ test_description='our own option parser'
 
 . ./test-lib.sh
 
-cat > expect << EOF
+cat >expect <<\EOF
 usage: test-parse-options <options>
 
     --yes                 get a boolean
@@ -49,14 +49,14 @@ Standard options
 EOF
 
 test_expect_success 'test help' '
-	test_must_fail test-parse-options -h > output 2> output.err &&
+	test_must_fail test-parse-options -h >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_i18ncmp expect output
 '
 
 mv expect expect.err
 
-cat >expect.template <<EOF
+cat >expect.template <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -156,7 +156,7 @@ test_expect_success 'OPT_MAGNITUDE() 3giga' '
 	check magnitude: 3221225472 -m 3g
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -176,7 +176,7 @@ test_expect_success 'short options' '
 	test_must_be_empty output.err
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 2
 integer: 1729
 magnitude: 16384
@@ -204,7 +204,7 @@ test_expect_success 'missing required value' '
 	test_expect_code 129 test-parse-options --file
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 1
 integer: 13
 magnitude: 0
@@ -222,12 +222,12 @@ EOF
 
 test_expect_success 'intermingled arguments' '
 	test-parse-options a1 --string 123 b1 --boolean -j 13 -- --boolean \
-		> output 2> output.err &&
+		>output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 2
 magnitude: 0
@@ -241,13 +241,13 @@ file: (not set)
 EOF
 
 test_expect_success 'unambiguously abbreviated option' '
-	test-parse-options --int 2 --boolean --no-bo > output 2> output.err &&
+	test-parse-options --int 2 --boolean --no-bo >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'unambiguously abbreviated option with "="' '
-	test-parse-options --int=2 > output 2> output.err &&
+	test-parse-options --int=2 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
@@ -256,7 +256,7 @@ test_expect_success 'ambiguously abbreviated option' '
 	test_expect_code 129 test-parse-options --strin 123
 '
 
-cat > expect << EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -270,32 +270,32 @@ file: (not set)
 EOF
 
 test_expect_success 'non ambiguous option (after two options it abbreviates)' '
-	test-parse-options --st 123 > output 2> output.err &&
+	test-parse-options --st 123 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > typo.err << EOF
-error: did you mean \`--boolean\` (with two dashes ?)
+cat >typo.err <<\EOF
+error: did you mean `--boolean` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -boolean > output 2> output.err &&
+	test_must_fail test-parse-options -boolean >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > typo.err << EOF
-error: did you mean \`--ambiguous\` (with two dashes ?)
+cat >typo.err <<\EOF
+error: did you mean `--ambiguous` (with two dashes ?)
 EOF
 
 test_expect_success 'detect possible typos' '
-	test_must_fail test-parse-options -ambiguous > output 2> output.err &&
+	test_must_fail test-parse-options -ambiguous >output 2>output.err &&
 	test_must_be_empty output &&
 	test_cmp typo.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -310,12 +310,12 @@ arg 00: --quux
 EOF
 
 test_expect_success 'keep some options as arguments' '
-	test-parse-options --quux > output 2> output.err &&
+	test-parse-options --quux >output 2>output.err &&
 	test_must_be_empty output.err &&
-        test_cmp expect output
+	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -331,12 +331,12 @@ EOF
 
 test_expect_success 'OPT_DATE() works' '
 	test-parse-options -t "1970-01-01 00:00:01 +0000" \
-		foo -q > output 2> output.err &&
+		foo -q >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 Callback: "four", 0
 boolean: 5
 integer: 4
@@ -351,22 +351,22 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_CALLBACK() and OPT_BIT() work' '
-	test-parse-options --length=four -b -4 > output 2> output.err &&
+	test-parse-options --length=four -b -4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 Callback: "not set", 1
 EOF
 
 test_expect_success 'OPT_CALLBACK() and callback errors work' '
-	test_must_fail test-parse-options --no-length > output 2> output.err &&
+	test_must_fail test-parse-options --no-length >output 2>output.err &&
 	test_i18ncmp expect output &&
 	test_i18ncmp expect.err output.err
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 1
 integer: 23
 magnitude: 0
@@ -380,18 +380,18 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --no-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --no-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() and OPT_SET_INT() work' '
-	test-parse-options --set23 -bbbbb --neg-or4 > output 2> output.err &&
+	test-parse-options --set23 -bbbbb --neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 6
 integer: 0
 magnitude: 0
@@ -405,24 +405,24 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_BIT() works' '
-	test-parse-options -bb --or4 > output 2> output.err &&
+	test-parse-options -bb --or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_NEGBIT() works' '
-	test-parse-options -bb --no-neg-or4 > output 2> output.err &&
+	test-parse-options -bb --no-neg-or4 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
 test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
-	test-parse-options + + + + + + > output 2> output.err &&
+	test-parse-options + + + + + + >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat > expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 12345
 magnitude: 0
@@ -436,12 +436,12 @@ file: (not set)
 EOF
 
 test_expect_success 'OPT_NUMBER_CALLBACK() works' '
-	test-parse-options -12345 > output 2> output.err &&
+	test-parse-options -12345 >output 2>output.err &&
 	test_must_be_empty output.err &&
 	test_cmp expect output
 '
 
-cat >expect <<EOF
+cat >expect <<\EOF
 boolean: 0
 integer: 0
 magnitude: 0
@@ -460,7 +460,7 @@ test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test_cmp expect output
 '
 
-cat >>expect <<'EOF'
+cat >>expect <<\EOF
 list: foo
 list: bar
 list: baz

--
https://github.com/git/git/pull/218

[PATCH v14 6/6] commit: add a commit.verbose config variable

[Pranit Bauva]

Add commit.verbose configuration variable as a convenience for those
who always prefer --verbose.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The previous version of the patch are:
 - [v12] $gmane/288820
 - [v11] $gmane/288820
 - [v10] $gmane/288820
 - [v9] $gmane/288820
 - [v8] $gmane/288820
 - [v7] $gmane/288820
 - [v6] $gmane/288728
 - [v5] $gmane/288728
 - [v4] $gmane/288652
 - [v3] $gmane/288634
 - [v2] $gmane/288569
 - [v1] $gmane/287540

   Note: One might think some tests are extra but I think that it will
   be better to include them as they "complete the continuity" thus
   generalising the series which will make the patch even more clearer.

Changes wrt v12:
 - Change the setup test as suggested by Eric.
 - Use for loops for systematic testing. I have avoided nested-for loops
   or using a function to test because I believe it will just add to the
   complexity rather than simplifying it. Just by using for loops the
   tests look quite systematic and easy to digest.
---
 Documentation/config.txt     |  4 ++++
 Documentation/git-commit.txt |  3 ++-
 builtin/commit.c             | 14 ++++++++++-
 t/t7507-commit-verbose.sh    | 56 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2cd6bdd..1d0ec2e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1110,6 +1110,10 @@ commit.template::
 	"`~/`" is expanded to the value of `$HOME` and "`~user/`" to the
 	specified user's home directory.
 
+commit.verbose::
+	A boolean or int to specify the level of verbose with `git commit`.
+	See linkgit:git-commit[1].
+
 credential.helper::
 	Specify an external helper to be called when a username or
 	password credential is needed; the helper may consult external
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 9ec6b3c..d474226 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -290,7 +290,8 @@ configuration variable documented in linkgit:git-config[1].
 	what changes the commit has.
 	Note that this diff output doesn't have its
 	lines prefixed with '#'. This diff will not be a part
-	of the commit message.
+	of the commit message. See the `commit.verbose` configuration
+	variable in linkgit:git-config[1].
 +
 If specified twice, show in addition the unified diff between
 what would be committed and the worktree files, i.e. the unstaged
diff --git a/builtin/commit.c b/builtin/commit.c
index b3bd2d4..96e6190 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,7 +113,9 @@ static char *edit_message, *use_message;
 static char *fixup_message, *squash_message;
 static int all, also, interactive, patch_interactive, only, amend, signoff;
 static int edit_flag = -1; /* unspecified */
-static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
+static int config_verbose = -1; /* unspecified */
+static int verbose = -1; /* unspecified */
+static int quiet, no_verify, allow_empty, dry_run, renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
@@ -1354,6 +1356,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 			     builtin_status_usage, 0);
 	finalize_colopts(&s.colopts, -1);
 	finalize_deferred_config(&s);
+	if (verbose == -1)
+		verbose = 0;
 
 	handle_untracked_files_arg(&s);
 	if (show_ignored_in_status)
@@ -1505,6 +1509,11 @@ static int git_commit_config(const char *k, const char *v, void *cb)
 		sign_commit = git_config_bool(k, v) ? "" : NULL;
 		return 0;
 	}
+	if (!strcmp(k, "commit.verbose")) {
+		int is_bool;
+		config_verbose = git_config_bool_or_int(k, v, &is_bool);
+		return 0;
+	}
 
 	status = git_gpg_config(k, v, NULL);
 	if (status)
@@ -1654,6 +1663,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	argc = parse_and_validate_options(argc, argv, builtin_commit_options,
 					  builtin_commit_usage,
 					  prefix, current_head, &s);
+	if (verbose == -1)
+		verbose = (config_verbose < 0) ? 0 : config_verbose;
+
 	if (dry_run)
 		return dry_run_commit(argc, argv, prefix, current_head, &s);
 	index_file = prepare_index(argc, argv, prefix, current_head, 0);
diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 0f28a86..00e0c3d 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -98,4 +98,60 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
 	test_i18ngrep "Aborting commit due to empty commit message." err
 '
 
+test_expect_success 'setup -v -v' '
+	echo dirty >file
+'
+
+for i in true 1
+do
+	test_expect_success "commit.verbose=$i and --verbose omitted" "
+		git -c commit.verbose=$i commit --amend &&
+		test_line_count = 1 out
+	"
+done
+
+for i in false -2 -1 0
+do
+	test_expect_success "commit.verbose=$i and --verbose omitted" "
+		git -c commit.verbose=$i commit --amend &&
+		test_line_count = 0 out
+	"
+done
+
+for i in 2 3
+do
+	test_expect_success "commit.verbose=$i and --verbose omitted" "
+		git -c commit.verbose=$i commit --amend &&
+		test_line_count = 2 out
+	"
+done
+
+for i in true false -2 -1 0 1 2 3
+do
+	test_expect_success "commit.verbose=$i and --verbose" "
+		git -c commit.verbose=$i commit --amend --verbose &&
+		test_line_count = 1 out
+	"
+
+	test_expect_success "commit.verbose=$i and --no-verbose" "
+		git -c commit.verbose=$i commit --amend --no-verbose &&
+		test_line_count = 0 out
+	"
+
+	test_expect_success "commit.verbose=$i and -v -v" "
+		git -c commit.verbose=$i commit --amend -v -v &&
+		test_line_count = 2 out
+	"
+done
+
+test_expect_success 'status ignores commit.verbose=true' '
+	git -c commit.verbose=true status >actual &&
+	! grep "^diff --git" actual
+'
+
+test_expect_success 'status does not verbose without --verbose' '
+	git status >actual &&
+	! grep "^diff --git" actual
+'
+
 test_done

--
https://github.com/git/git/pull/218

[PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

OPT_COUNTUP() merely increments the counter upon --option, and resets it
to 0 upon --no-option, which means that there is no "unspecified" value
with which a client can initialize the counter to determine whether or
not --[no]-option was seen at all.

Make OPT_COUNTUP() treat any negative number as an "unspecified" value
to address this shortcoming. In particular, if a client initializes the
counter to -1, then if it is still -1 after parse_options(), then
neither --option nor --no-option was seen; If it is 0, then --no-option
was seen last, and if it is 1 or greater, than --option was seen last.

This change does not affect the behavior of existing clients because
they all use the initial value of 0 (or more).

Note that builtin/clean.c initializes the variable used with
OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
to either 0 or 1 by reading the configuration before the code calls
parse_options(), i.e. as far as parse_options() is concerned, the
initial value of the variable is not negative.

To test this behavior, in test-parse-options.c, "verbose" is set to
"unspecified" while quiet is set to 0 which will test the new behavior
with all sets of values.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
The discussion about this patch:
[1] : http://thread.gmane.org/gmane.comp.version-control.git/289027

Previous version of the patch:
[v11] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v10] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v9] : http://thread.gmane.org/gmane.comp.version-control.git/288820
[v1] : http://thread.gmane.org/gmane.comp.version-control.git/289061

Changes wrt previous version (v13):
 - Some tests failed in v12 as the newly introduced tests weren't
   updated by the behaviour of this patch.

Please Note: The diff might seem improper especially the part where I
have introduced some continuous lines but this is a logical error by git
diff (nothing could be done about it) and thus the changes will be
clearly visible with the original file itself.
---
 Documentation/technical/api-parse-options.txt |  8 +++--
 parse-options.c                               |  2 ++
 t/t0040-parse-options.sh                      | 43 +++++++++++++++++++--------
 test-parse-options.c                          |  3 +-
 4 files changed, 41 insertions(+), 15 deletions(-)

diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
index 5f0757d..8908bf7 100644
--- a/Documentation/technical/api-parse-options.txt
+++ b/Documentation/technical/api-parse-options.txt
@@ -144,8 +144,12 @@ There are some macros to easily define options:
 
 `OPT_COUNTUP(short, long, &int_var, description)`::
 	Introduce a count-up option.
-	`int_var` is incremented on each use of `--option`, and
-	reset to zero with `--no-option`.
+	Each use of `--option` increments `int_var`, starting from zero
+	(even if initially negative), and `--no-option` resets it to
+	zero. To determine if `--option` or `--no-option` was set at
+	all, set `int_var` to a negative value, and if it is still
+	negative after parse_options(), then neither `--option` nor
+	`--no-option` was seen.
 
 `OPT_BIT(short, long, &int_var, description, mask)`::
 	Introduce a boolean option.
diff --git a/parse-options.c b/parse-options.c
index 47a9192..312a85d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -110,6 +110,8 @@ static int get_value(struct parse_opt_ctx_t *p,
 		return 0;
 
 	case OPTION_COUNTUP:
+		if (*(int *)opt->value < 0)
+			*(int *)opt->value = 0;
 		*(int *)opt->value = unset ? 0 : *(int *)opt->value + 1;
 		return 0;
 
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index c913d1c..d3f52f6 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -63,7 +63,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -211,7 +211,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -234,7 +234,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -263,7 +263,7 @@ magnitude: 0
 timestamp: 0
 string: 123
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -302,7 +302,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -322,7 +322,7 @@ magnitude: 0
 timestamp: 1
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 1
 dry run: no
 file: (not set)
@@ -344,7 +344,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -373,7 +373,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -398,7 +398,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -429,7 +429,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
@@ -454,6 +454,25 @@ dry run: no
 file: (not set)
 EOF
 
+test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
+	test-parse-options --no-verbose >output 2>output.err &&
+	test_must_be_empty output.err &&
+	test_cmp expect output
+'
+
+cat >expect <<EOF
+boolean: 0
+integer: 0
+magnitude: 0
+timestamp: 0
+string: (not set)
+abbrev: 7
+verbose: -1
+quiet: 0
+dry run: no
+file: (not set)
+EOF
+
 test_expect_success 'negation of OPT_NONEG flags is not ambiguous' '
 	test-parse-options --no-ambig >output 2>output.err &&
 	test_must_be_empty output.err &&
@@ -483,7 +502,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 3
 dry run: no
 file: (not set)
@@ -502,7 +521,7 @@ magnitude: 0
 timestamp: 0
 string: (not set)
 abbrev: 7
-verbose: 0
+verbose: -1
 quiet: 0
 dry run: no
 file: (not set)
diff --git a/test-parse-options.c b/test-parse-options.c
index 86afa98..f02c275 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -7,7 +7,8 @@ static int integer = 0;
 static unsigned long magnitude = 0;
 static unsigned long timestamp;
 static int abbrev = 7;
-static int verbose = 0, dry_run = 0, quiet = 0;
+static int verbose = -1; /* unspecified */
+static int dry_run = 0, quiet = 0;
 static char *string = NULL;
 static char *file = NULL;
 static int ambiguous;

--
https://github.com/git/git/pull/218

[PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

Make the fake "editor" store output of grep in a file so that we can
see how many diffs were contained in the message and use them in
individual tests where ever it is required. A subsequent commit will
introduce scenarios where it is important to be able to exactly
determine how many diffs were present.

Also use write_script() to create the fake "editor".

The fake "editor" is always made to succeed regardless of whether grep
found diff headers or not so that we don't have to use 'test_must_fail'
for which 'test_line_count = 0' is an easy substitute and also helps in
maintaining the consistency.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

---
Previous version of this patch:
 - [v12] : $gmane/288820
 - [v11] : $gmane/288820
 - [v10]: $gmane/288820

Changes this version wrt previous one:
Change the commit message as suggested by Eric
---
 t/t7507-commit-verbose.sh | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
index 2ddf28c..0f28a86 100755
--- a/t/t7507-commit-verbose.sh
+++ b/t/t7507-commit-verbose.sh
@@ -3,11 +3,10 @@
 test_description='verbose commit template'
 . ./test-lib.sh
 
-cat >check-for-diff <<EOF
-#!$SHELL_PATH
-exec grep '^diff --git' "\$1"
+write_script "check-for-diff" <<\EOF &&
+grep '^diff --git' "$1" >out
+exit 0
 EOF
-chmod +x check-for-diff
 test_set_editor "$PWD/check-for-diff"
 
 cat >message <<'EOF'
@@ -23,7 +22,8 @@ test_expect_success 'setup' '
 '
 
 test_expect_success 'initial commit shows verbose diff' '
-	git commit --amend -v
+	git commit --amend -v &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'second commit' '
@@ -39,13 +39,15 @@ check_message() {
 
 test_expect_success 'verbose diff is stripped out' '
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 test_expect_success 'verbose diff is stripped out (mnemonicprefix)' '
 	git config diff.mnemonicprefix true &&
 	git commit --amend -v &&
-	check_message message
+	check_message message &&
+	test_line_count = 1 out
 '
 
 cat >diff <<'EOF'

--
https://github.com/git/git/pull/218

Re: [PATCH v13 2/6] test-parse-options: print quiet as integer

[Junio C Hamano]

Pranit Bauva <pranit.bauva@gmail.com> writes:

> On Wed, Apr 13, 2016 at 3:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Pranit Bauva <pranit.bauva@gmail.com> writes:
>>
>>> Current implementation of parse-options.c treats OPT__QUIET() as integer
>>> and not boolean and thus it is more appropriate to print it as integer
>>> to avoid confusion.
>>
>> There is no "confusion" factor involved, as we do not use native
>> "boolean" type in our C code.  IIUC, the reason why we want to do
>> this is because we may want to see how it would affect the value of
>> the underlying variable to give multiple --quiet options from the
>> command line, which is a policy issue (i.e. we want to allow
>> commands to react to multiple quiet options differently), not an
>> implementation one (i.e. "current implementation happens to use
>> integer").
>>
>>         We would want to see how multiple --quiet options affect the
>>         value of the underlying variable (we may want "--quiet --quiet"
>>         to still be 1, or we may want to see the value incremented
>>         to 2).  Show the value as integer to allow us to inspect it.
>>
>> perhaps?
>
> This commit message does look a lot better. I will re-roll this.

You need to pick which one you want inside the (parentheses),
though.  After reading 3/6 I am guessing that that you wanted the
latter.

> Should I just send an update of this patch or the whole series?

The latter, for a series this small.

Thanks.

Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage

[Eric Sunshine]

On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Include tests to check for multiple levels of quiet and to check if the
> '--no-quiet' option sets it to 0.
>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> @@ -476,4 +476,41 @@ test_expect_success '--no-list resets list' '
> +cat >expect <<\EOF
> +boolean: 0
> +integer: 0
> +magnitude: 0
> +timestamp: 0
> +string: (not set)
> +abbrev: 7
> +verbose: 0
> +quiet: 0
> +dry run: no
> +file: (not set)
> +EOF
> +
> +test_expect_success '--no-quiet sets quiet to 0' '
> +       test-parse-options --no-quiet >output 2>output.err &&

Meh, as implemented, this isn't a very interesting test, is it?
'quiet' started at 0, so all this shows is that --no-quiet didn't
disturb the 0. To really test that it resets it to 0, you'd want:

    test-parse-options --quiet --no-quiet >... 2>... &&

> +       test_must_be_empty output.err &&
> +       test_cmp expect output
> +'
>  test_done

Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Eric Sunshine]

On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> OPT_COUNTUP() merely increments the counter upon --option, and resets it
> to 0 upon --no-option, which means that there is no "unspecified" value
> with which a client can initialize the counter to determine whether or
> not --[no]-option was seen at all.
>
> Make OPT_COUNTUP() treat any negative number as an "unspecified" value
> to address this shortcoming. In particular, if a client initializes the
> counter to -1, then if it is still -1 after parse_options(), then
> neither --option nor --no-option was seen; If it is 0, then --no-option
> was seen last, and if it is 1 or greater, than --option was seen last.

Nit: I'm pretty sure that when I wrote this commit message for you[1]
the "if" following the semicolon was correctly lowercase. It's not
clear why it got incorrectly capitalized here.

More below...

> This change does not affect the behavior of existing clients because
> they all use the initial value of 0 (or more).
>
> Note that builtin/clean.c initializes the variable used with
> OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
> to either 0 or 1 by reading the configuration before the code calls
> parse_options(), i.e. as far as parse_options() is concerned, the
> initial value of the variable is not negative.
>
> To test this behavior, in test-parse-options.c, "verbose" is set to
> "unspecified" while quiet is set to 0 which will test the new behavior
> with all sets of values.
>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
> @@ -144,8 +144,12 @@ There are some macros to easily define options:
>  `OPT_COUNTUP(short, long, &int_var, description)`::
>         Introduce a count-up option.
> -       `int_var` is incremented on each use of `--option`, and
> -       reset to zero with `--no-option`.
> +       Each use of `--option` increments `int_var`, starting from zero
> +       (even if initially negative), and `--no-option` resets it to
> +       zero. To determine if `--option` or `--no-option` was set at

Repeating from [1]: s/was set/was encountered/

> +       all, set `int_var` to a negative value, and if it is still

Repeating from [1] and [2]: s/set `int_var`/initialize `int_var`/

> +       negative after parse_options(), then neither `--option` nor
> +       `--no-option` was seen.
> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
> @@ -454,6 +454,25 @@ dry run: no
> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '

What is "--no- flag"?

> +       test-parse-options --no-verbose >output 2>output.err &&
> +       test_must_be_empty output.err &&
> +       test_cmp expect output
> +'

In my v12 review, I noticed that neither --no-verbose nor --no-quiet
was being tested by t0040 (which is conceptually independent of the
OPT__COUNTUP change) and suggested[3] that you add a new patch to
address that shortcoming. This idea was followed up by [1] saying that
this test (here) could then be dropped since the case it checks would
already be covered by the new patch. My impression was that you
agreed[4] that that made sense, however, this test is still here. Did
I misunderstand your response[4]?

[1]: http://article.gmane.org/gmane.comp.version-control.git/290662
[2]: http://article.gmane.org/gmane.comp.version-control.git/289991
[3]: http://article.gmane.org/gmane.comp.version-control.git/290655
[4]: http://article.gmane.org/gmane.comp.version-control.git/290787

Re: [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs

[Eric Sunshine]

On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Make the fake "editor" store output of grep in a file so that we can
> see how many diffs were contained in the message and use them in
> individual tests where ever it is required. A subsequent commit will
> introduce scenarios where it is important to be able to exactly
> determine how many diffs were present.
>
> Also use write_script() to create the fake "editor".
>
> The fake "editor" is always made to succeed regardless of whether grep
> found diff headers or not so that we don't have to use 'test_must_fail'
> for which 'test_line_count = 0' is an easy substitute and also helps in
> maintaining the consistency.

As mentioned by [1], the change to write_script() is a minor aside; it
is less important than the explanation of how and why the return value
of the fake "editor" changed, thus the order of the 2nd and 3rd
paragraphs should be swapped.

[1]: http://article.gmane.org/gmane.comp.version-control.git/290663

> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

Re: [PATCH v14 6/6] commit: add a commit.verbose config variable

[Eric Sunshine]

On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> Add commit.verbose configuration variable as a convenience for those
> who always prefer --verbose.
>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> diff --git a/t/t7507-commit-verbose.sh b/t/t7507-commit-verbose.sh
> @@ -98,4 +98,60 @@ test_expect_success 'verbose diff is stripped out with set core.commentChar' '
> +test_expect_success 'status ignores commit.verbose=true' '
> +       git -c commit.verbose=true status >actual &&
> +       ! grep "^diff --git" actual
> +'

I understand what this test is checking, as it is in response to
Junio's suggestion[1]...

> +test_expect_success 'status does not verbose without --verbose' '
> +       git status >actual &&
> +       ! grep "^diff --git" actual
> +'

But what is this test checking?

> +
>  test_done

[1]: http://article.gmane.org/gmane.comp.version-control.git/288648

Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

On Wed, Apr 13, 2016 at 11:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> OPT_COUNTUP() merely increments the counter upon --option, and resets it
>> to 0 upon --no-option, which means that there is no "unspecified" value
>> with which a client can initialize the counter to determine whether or
>> not --[no]-option was seen at all.
>>
>> Make OPT_COUNTUP() treat any negative number as an "unspecified" value
>> to address this shortcoming. In particular, if a client initializes the
>> counter to -1, then if it is still -1 after parse_options(), then
>> neither --option nor --no-option was seen; If it is 0, then --no-option
>> was seen last, and if it is 1 or greater, than --option was seen last.
>
> Nit: I'm pretty sure that when I wrote this commit message for you[1]
> the "if" following the semicolon was correctly lowercase. It's not
> clear why it got incorrectly capitalized here.

A typo. Will fix it if re-rolled

> More below...
>
>> This change does not affect the behavior of existing clients because
>> they all use the initial value of 0 (or more).
>>
>> Note that builtin/clean.c initializes the variable used with
>> OPT__FORCE (which uses OPT_COUNTUP()) to a negative value, but it is set
>> to either 0 or 1 by reading the configuration before the code calls
>> parse_options(), i.e. as far as parse_options() is concerned, the
>> initial value of the variable is not negative.
>>
>> To test this behavior, in test-parse-options.c, "verbose" is set to
>> "unspecified" while quiet is set to 0 which will test the new behavior
>> with all sets of values.
>>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/Documentation/technical/api-parse-options.txt b/Documentation/technical/api-parse-options.txt
>> @@ -144,8 +144,12 @@ There are some macros to easily define options:
>>  `OPT_COUNTUP(short, long, &int_var, description)`::
>>         Introduce a count-up option.
>> -       `int_var` is incremented on each use of `--option`, and
>> -       reset to zero with `--no-option`.
>> +       Each use of `--option` increments `int_var`, starting from zero
>> +       (even if initially negative), and `--no-option` resets it to
>> +       zero. To determine if `--option` or `--no-option` was set at
>
> Repeating from [1]: s/was set/was encountered/
>
>> +       all, set `int_var` to a negative value, and if it is still
>
> Repeating from [1] and [2]: s/set `int_var`/initialize `int_var`/

Will include this if re-rolled.
>
>> +       negative after parse_options(), then neither `--option` nor
>> +       `--no-option` was seen.
>> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
>> @@ -454,6 +454,25 @@ dry run: no
>> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
>
> What is "--no- flag"?
>
>> +       test-parse-options --no-verbose >output 2>output.err &&
>> +       test_must_be_empty output.err &&
>> +       test_cmp expect output
>> +'
>
> In my v12 review, I noticed that neither --no-verbose nor --no-quiet
> was being tested by t0040 (which is conceptually independent of the
> OPT__COUNTUP change) and suggested[3] that you add a new patch to
> address that shortcoming. This idea was followed up by [1] saying that
> this test (here) could then be dropped since the case it checks would
> already be covered by the new patch. My impression was that you
> agreed[4] that that made sense, however, this test is still here. Did
> I misunderstand your response[4]?
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/290662
> [2]: http://article.gmane.org/gmane.comp.version-control.git/289991
> [3]: http://article.gmane.org/gmane.comp.version-control.git/290655
> [4]: http://article.gmane.org/gmane.comp.version-control.git/290787

I actually did include the tests in the patch 3/6[1]. I mentioned in
my response[2] that I will include the tests between 2/5 and 3/5.
Since, after that no email was exchanged, I thought you agreed.

[1]: http://article.gmane.org/gmane.comp.version-control.git/291310
[2]:http://article.gmane.org/gmane.comp.version-control.git/290787

Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage

[Pranit Bauva]

On Wed, Apr 13, 2016 at 10:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Include tests to check for multiple levels of quiet and to check if the
>> '--no-quiet' option sets it to 0.
>>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
>> ---
>> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
>> @@ -476,4 +476,41 @@ test_expect_success '--no-list resets list' '
>> +cat >expect <<\EOF
>> +boolean: 0
>> +integer: 0
>> +magnitude: 0
>> +timestamp: 0
>> +string: (not set)
>> +abbrev: 7
>> +verbose: 0
>> +quiet: 0
>> +dry run: no
>> +file: (not set)
>> +EOF
>> +
>> +test_expect_success '--no-quiet sets quiet to 0' '
>> +       test-parse-options --no-quiet >output 2>output.err &&
>
> Meh, as implemented, this isn't a very interesting test, is it?
> 'quiet' started at 0, so all this shows is that --no-quiet didn't
> disturb the 0. To really test that it resets it to 0, you'd want:
>
>     test-parse-options --quiet --no-quiet >... 2>... &&
>
>> +       test_must_be_empty output.err &&
>> +       test_cmp expect output
>> +'
>>  test_done

This is to test whether the 0 of quiet remains 0 if --no-quiet is
included. This test "defines" the current behavior. Then when I change
OPT_COUNTUP(), this test will ensure that this behavior is not
interrupted as promised by the commit message of that patch[1]. I
guess this also describe why I choose to include these tests between
2/5 and 3/5 rather than 3/5 and 4/5. And also see the extended
discussion[2] for this. If I do a re-roll then I include `--quiet`
before `--no-quiet`

[1]: http://article.gmane.org/gmane.comp.version-control.git/291313

Re: [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs

[Pranit Bauva]

On Wed, Apr 13, 2016 at 11:33 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> Make the fake "editor" store output of grep in a file so that we can
>> see how many diffs were contained in the message and use them in
>> individual tests where ever it is required. A subsequent commit will
>> introduce scenarios where it is important to be able to exactly
>> determine how many diffs were present.
>>
>> Also use write_script() to create the fake "editor".
>>
>> The fake "editor" is always made to succeed regardless of whether grep
>> found diff headers or not so that we don't have to use 'test_must_fail'
>> for which 'test_line_count = 0' is an easy substitute and also helps in
>> maintaining the consistency.
>
> As mentioned by [1], the change to write_script() is a minor aside; it
> is less important than the explanation of how and why the return value
> of the fake "editor" changed, thus the order of the 2nd and 3rd
> paragraphs should be swapped.
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/290663

I will include this if I do a re-roll
>
>> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
>> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

Re: [PATCH v14 6/6] commit: add a commit.verbose config variable

[Pranit Bauva]

On Wed, Apr 13, 2016 at 11:44 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>
>> +test_expect_success 'status does not verbose without --verbose' '
>> +       git status >actual &&
>> +       ! grep "^diff --git" actual
>> +'
>
> But what is this test checking?

status is also a consumer of the verbose whose initial value is set to
-1. This makes it include verbose in status output. This bug was fixed
by explicitly initializing verbose to 0 if -1. SZEDER pointed out a
bug[1] which broke some tests in and then when I fixed it, you
requested me to include tests even in this patch[2] which I found
convincing enough.

[1]: http://article.gmane.org/gmane.comp.version-control.git/289730
[2]: http://article.gmane.org/gmane.comp.version-control.git/289993

Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage

[Eric Sunshine]

On Wed, Apr 13, 2016 at 4:59 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 10:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> +test_expect_success '--no-quiet sets quiet to 0' '
>>> +       test-parse-options --no-quiet >output 2>output.err &&
>>
>> Meh, as implemented, this isn't a very interesting test, is it?
>> 'quiet' started at 0, so all this shows is that --no-quiet didn't
>> disturb the 0. To really test that it resets it to 0, you'd want:
>>
>>     test-parse-options --quiet --no-quiet >... 2>... &&
>>
>>> +       test_must_be_empty output.err &&
>>> +       test_cmp expect output
>>> +'
>>>  test_done
>
> This is to test whether the 0 of quiet remains 0 if --no-quiet is
> included. This test "defines" the current behavior. Then when I change
> OPT_COUNTUP(), this test will ensure that this behavior is not
> interrupted as promised by the commit message of that patch[1]. I
> guess this also describe why I choose to include these tests between
> 2/5 and 3/5 rather than 3/5 and 4/5. And also see the extended
> discussion[2] for this. If I do a re-roll then I include `--quiet`
> before `--no-quiet`

Each of these patches should have a single conceptual purpose. It
seems, from the above explanation, that you're mixing and mismatching
bits of such changes between patches.

* The two new tests for --no-verbose and --no-quiet should be together
and check that they correctly reverse --verbose and --quiet,
respectively.

* The test you describe above which ensures that --no-quiet leaves
'quiet' at 0 should be bundled with the change that might break that
behavior, namely, the OPT__COUNTUP() change.

Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Eric Sunshine]

On Wed, Apr 13, 2016 at 4:39 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 11:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
>>> +       test-parse-options --no-verbose >output 2>output.err &&
>>> +       test_must_be_empty output.err &&
>>> +       test_cmp expect output
>>> +'
>>
>> In my v12 review, I noticed that neither --no-verbose nor --no-quiet
>> was being tested by t0040 (which is conceptually independent of the
>> OPT__COUNTUP change) and suggested[3] that you add a new patch to
>> address that shortcoming. This idea was followed up by [1] saying that
>> this test (here) could then be dropped since the case it checks would
>> already be covered by the new patch. My impression was that you
>> agreed[4] that that made sense, however, this test is still here. Did
>> I misunderstand your response[4]?
>>
>> [1]: http://article.gmane.org/gmane.comp.version-control.git/290662
>> [2]: http://article.gmane.org/gmane.comp.version-control.git/289991
>> [3]: http://article.gmane.org/gmane.comp.version-control.git/290655
>> [4]: http://article.gmane.org/gmane.comp.version-control.git/290787
>
> I actually did include the tests in the patch 3/6[1]. I mentioned in
> my response[2] that I will include the tests between 2/5 and 3/5.
> Since, after that no email was exchanged, I thought you agreed.

I'm not sure that I understand what you are saying since the
--no-verbose test does not seem to be included in the patch you cite
(it is instead in the present patch under discussion).

Perhaps there is some miscommunication and misunderstanding.

> [1]: http://article.gmane.org/gmane.comp.version-control.git/291310
> [2]:http://article.gmane.org/gmane.comp.version-control.git/290787

Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Pranit Bauva]

On Wed, Apr 13, 2016 at 11:03 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Wed, Apr 13, 2016 at 4:39 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Wed, Apr 13, 2016 at 11:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>>> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
>>>> +       test-parse-options --no-verbose >output 2>output.err &&
>>>> +       test_must_be_empty output.err &&
>>>> +       test_cmp expect output
>>>> +'
>>>
>>> In my v12 review, I noticed that neither --no-verbose nor --no-quiet
>>> was being tested by t0040 (which is conceptually independent of the
>>> OPT__COUNTUP change) and suggested[3] that you add a new patch to
>>> address that shortcoming. This idea was followed up by [1] saying that
>>> this test (here) could then be dropped since the case it checks would
>>> already be covered by the new patch. My impression was that you
>>> agreed[4] that that made sense, however, this test is still here. Did
>>> I misunderstand your response[4]?
>>>
>>> [1]: http://article.gmane.org/gmane.comp.version-control.git/290662
>>> [2]: http://article.gmane.org/gmane.comp.version-control.git/289991
>>> [3]: http://article.gmane.org/gmane.comp.version-control.git/290655
>>> [4]: http://article.gmane.org/gmane.comp.version-control.git/290787
>>
>> I actually did include the tests in the patch 3/6[1]. I mentioned in
>> my response[2] that I will include the tests between 2/5 and 3/5.
>> Since, after that no email was exchanged, I thought you agreed.
>
> I'm not sure that I understand what you are saying since the
> --no-verbose test does not seem to be included in the patch you cite
> (it is instead in the present patch under discussion).
>
> Perhaps there is some miscommunication and misunderstanding.

Sorry for being a bit unclear.
I will explain this. The patch 3/6 contains the test which tests the
quiet option thus in turn testing whether the variable quiet becomes 0
with --no flag. This patch ie. 4/6 contains the test which tests the
verbose options thus in turn testing whether the variable verbose
becomes 0 with no flag. Both of them test different behavior as quiet
is initially 0 while verbose is initially -1.

So finally what I wanted to achieve is that I should test --no-quiet
in 3/6 as till then this new behavior is not yet introduced. Thus, it
will confirm the wanted behavior which exists before 4/6.

This patch introduces a test to verify whether --no-verbose makes the
variable 0. This patch introduces a new "unspecified" behavior. Thus
we can test this new behavior with this.

I hope now it is a bit clear on what I want to do.

>> [1]: http://article.gmane.org/gmane.comp.version-control.git/291310
>> [2]:http://article.gmane.org/gmane.comp.version-control.git/290787

Re: [PATCH v14 6/6] commit: add a commit.verbose config variable

[Eric Sunshine]

On Wed, Apr 13, 2016 at 5:15 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 11:44 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> +test_expect_success 'status does not verbose without --verbose' '
>>> +       git status >actual &&
>>> +       ! grep "^diff --git" actual
>>> +'
>>
>> But what is this test checking?
>
> status is also a consumer of the verbose whose initial value is set to
> -1. This makes it include verbose in status output. This bug was fixed
> by explicitly initializing verbose to 0 if -1. SZEDER pointed out a
> bug[1] which broke some tests in and then when I fixed it, you
> requested me to include tests even in this patch[2] which I found
> convincing enough.
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/289730
> [2]: http://article.gmane.org/gmane.comp.version-control.git/289993

Okay, makes sense, but it's not at all obvious from the context of
this patch or its commit message. It probably would have been clearer
had the two git-status tests been added in a separate preparatory test
with a commit message explaining that the tests are to ensure that a
subsequent patch (adding commit.verbose) won't break the existing
behavior of git-status. Having a separate commit explaining that would
also help future readers of the test script who wonder what this test
is doing (since it's not obvious and it's not explained by the current
commit message) when they use git-blame to try to figure out its
purpose. If you do re-roll, you might consider breaking them out to a
new patch or, at the very least, document their purpose in the commit
message of this patch.

Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values

[Eric Sunshine]

On Wed, Apr 13, 2016 at 1:43 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 11:03 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Wed, Apr 13, 2016 at 4:39 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>> On Wed, Apr 13, 2016 at 11:26 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>>> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>>>> +test_expect_success 'OPT_COUNTUP() resets to 0 with --no- flag' '
>>>>> +       test-parse-options --no-verbose >output 2>output.err &&
>>>>> +       test_must_be_empty output.err &&
>>>>> +       test_cmp expect output
>>>>> +'
>>>>
>>>> In my v12 review, I noticed that neither --no-verbose nor --no-quiet
>>>> was being tested by t0040 (which is conceptually independent of the
>>>> OPT__COUNTUP change) and suggested[3] that you add a new patch to
>>>> address that shortcoming. This idea was followed up by [1] saying that
>>>> this test (here) could then be dropped since the case it checks would
>>>> already be covered by the new patch. My impression was that you
>>>> agreed[4] that that made sense, however, this test is still here. Did
>>>> I misunderstand your response[4]?
>>>>
>>>> [1]: http://article.gmane.org/gmane.comp.version-control.git/290662
>>>> [2]: http://article.gmane.org/gmane.comp.version-control.git/289991
>>>> [3]: http://article.gmane.org/gmane.comp.version-control.git/290655
>>>> [4]: http://article.gmane.org/gmane.comp.version-control.git/290787
>>>
>>> I actually did include the tests in the patch 3/6[1]. I mentioned in
>>> my response[2] that I will include the tests between 2/5 and 3/5.
>>> Since, after that no email was exchanged, I thought you agreed.
>>
>> I'm not sure that I understand what you are saying since the
>> --no-verbose test does not seem to be included in the patch you cite
>> (it is instead in the present patch under discussion).
>>
>> Perhaps there is some miscommunication and misunderstanding.
>
> Sorry for being a bit unclear.
> I will explain this. The patch 3/6 contains the test which tests the
> quiet option thus in turn testing whether the variable quiet becomes 0
> with --no flag. This patch ie. 4/6 contains the test which tests the
> verbose options thus in turn testing whether the variable verbose
> becomes 0 with no flag. Both of them test different behavior as quiet
> is initially 0 while verbose is initially -1.
>
> So finally what I wanted to achieve is that I should test --no-quiet
> in 3/6 as till then this new behavior is not yet introduced. Thus, it
> will confirm the wanted behavior which exists before 4/6.
>
> This patch introduces a test to verify whether --no-verbose makes the
> variable 0. This patch introduces a new "unspecified" behavior. Thus
> we can test this new behavior with this.
>
> I hope now it is a bit clear on what I want to do.

Sorry, it's not clearer. I understand what you're trying to do, but it
still seems to be the a less desirable (and more complex) approach
since it's mixing conceptually distinct notions and mismatching them
with changes in the wrong patches. But, perhaps my notion of
"conceptually distinct" is different from yours and vice-versa.

Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage

[Pranit Bauva]

On Wed, Apr 13, 2016 at 10:57 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Wed, Apr 13, 2016 at 4:59 AM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Wed, Apr 13, 2016 at 10:56 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Tue, Apr 12, 2016 at 7:02 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>>>> +test_expect_success '--no-quiet sets quiet to 0' '
>>>> +       test-parse-options --no-quiet >output 2>output.err &&
>>>
>>> Meh, as implemented, this isn't a very interesting test, is it?
>>> 'quiet' started at 0, so all this shows is that --no-quiet didn't
>>> disturb the 0. To really test that it resets it to 0, you'd want:
>>>
>>>     test-parse-options --quiet --no-quiet >... 2>... &&
>>>
>>>> +       test_must_be_empty output.err &&
>>>> +       test_cmp expect output
>>>> +'
>>>>  test_done
>>
>> This is to test whether the 0 of quiet remains 0 if --no-quiet is
>> included. This test "defines" the current behavior. Then when I change
>> OPT_COUNTUP(), this test will ensure that this behavior is not
>> interrupted as promised by the commit message of that patch[1]. I
>> guess this also describe why I choose to include these tests between
>> 2/5 and 3/5 rather than 3/5 and 4/5. And also see the extended
>> discussion[2] for this. If I do a re-roll then I include `--quiet`
>> before `--no-quiet`
>
> Each of these patches should have a single conceptual purpose. It
> seems, from the above explanation, that you're mixing and mismatching
> bits of such changes between patches.
>
> * The two new tests for --no-verbose and --no-quiet should be together
> and check that they correctly reverse --verbose and --quiet,
> respectively.
>
> * The test you describe above which ensures that --no-quiet leaves
> 'quiet' at 0 should be bundled with the change that might break that
> behavior, namely, the OPT__COUNTUP() change.

I am planning to re-roll this.
So, I am just confirming whether I understood properly.

 * I will add the tests for check for '-q --no-quiet' instead of just
'--no-quiet' sets to 0 and '-v --no-verbose' sets to 0 in the patch
which improves test coverage which will be before the OPT_COUNTUP()
change.

 * I will then add the test for '--no-quiet' sets to 0 in the separate
patch after OPT_COUNTUP() change.

Is there something else or something different that you are suggesting?

Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage

[Eric Sunshine]

On Mon, Apr 25, 2016 at 2:40 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 10:57 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> Each of these patches should have a single conceptual purpose. It
>> seems, from the above explanation, that you're mixing and mismatching
>> bits of such changes between patches.
>>
>> * The two new tests for --no-verbose and --no-quiet should be together
>> and check that they correctly reverse --verbose and --quiet,
>> respectively.
>>
>> * The test you describe above which ensures that --no-quiet leaves
>> 'quiet' at 0 should be bundled with the change that might break that
>> behavior, namely, the OPT__COUNTUP() change.
>
> I am planning to re-roll this.
> So, I am just confirming whether I understood properly.
>
>  * I will add the tests for check for '-q --no-quiet' instead of just
> '--no-quiet' sets to 0 and '-v --no-verbose' sets to 0 in the patch
> which improves test coverage which will be before the OPT_COUNTUP()
> change.

These tests would be even a bit more interesting if you tested "-q -q
--no-quiet" and "-v -v --no-verbose", respectively, to ensure that the
"no" options actually reset to 0 rather than merely decrementing by 1.

I recall also suggesting adding a new test checking that "-q -q"
increments the quiet count to 2 (which could be done in the patch
which makes 'quiet' print as a number instead of a boolean or in the
same "improve test coverage" patch).

>  * I will then add the test for '--no-quiet' sets to 0 in the separate
> patch after OPT_COUNTUP() change.

No, this and "--no-verbose sets to 0" are logically related to the
OPT__COUNTUP() change, thus would be incorporated into that patch.
Alternately, these two tests could just be part of "improve test
coverage" patch, establishing base behavior which the OPT__COUNTUP()
patch shouldn't break.

Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage

[Pranit Bauva]

On Wed, Apr 27, 2016 at 11:25 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Mon, Apr 25, 2016 at 2:40 PM, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> On Wed, Apr 13, 2016 at 10:57 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> Each of these patches should have a single conceptual purpose. It
>>> seems, from the above explanation, that you're mixing and mismatching
>>> bits of such changes between patches.
>>>
>>> * The two new tests for --no-verbose and --no-quiet should be together
>>> and check that they correctly reverse --verbose and --quiet,
>>> respectively.
>>>
>>> * The test you describe above which ensures that --no-quiet leaves
>>> 'quiet' at 0 should be bundled with the change that might break that
>>> behavior, namely, the OPT__COUNTUP() change.
>>
>> I am planning to re-roll this.
>> So, I am just confirming whether I understood properly.
>>
>>  * I will add the tests for check for '-q --no-quiet' instead of just
>> '--no-quiet' sets to 0 and '-v --no-verbose' sets to 0 in the patch
>> which improves test coverage which will be before the OPT_COUNTUP()
>> change.
>
> These tests would be even a bit more interesting if you tested "-q -q
> --no-quiet" and "-v -v --no-verbose", respectively, to ensure that the
> "no" options actually reset to 0 rather than merely decrementing by 1.

This seems a better choice.

> I recall also suggesting adding a new test checking that "-q -q"
> increments the quiet count to 2 (which could be done in the patch
> which makes 'quiet' print as a number instead of a boolean or in the
> same "improve test coverage" patch).

Will include this.

>>  * I will then add the test for '--no-quiet' sets to 0 in the separate
>> patch after OPT_COUNTUP() change.
>
> No, this and "--no-verbose sets to 0" are logically related to the
> OPT__COUNTUP() change, thus would be incorporated into that patch.
> Alternately, these two tests could just be part of "improve test
> coverage" patch, establishing base behavior which the OPT__COUNTUP()
> patch shouldn't break.

I would prefer including it in "improve test coverage" patch to
establish the base behavior. This seems more natural to me.

You can expect this series from me within 2 days.

Thanks.