* [PATCH v7] commit: add a commit.verbose config variable @ 2016-03-14 21:38 Pranit Bauva 2016-03-15 11:31 ` SZEDER Gábor 2016-03-18 21:19 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 0 siblings, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-14 21:38 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-14 21:38 [PATCH v7] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-15 11:31 ` SZEDER Gábor 2016-03-15 19:00 ` Pranit Bauva 2016-03-18 21:19 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: SZEDER Gábor @ 2016-03-15 11:31 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, git > 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 11:31 ` SZEDER Gábor @ 2016-03-15 19:00 ` Pranit Bauva 2016-03-15 19:24 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-15 19:00 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 19:00 ` Pranit Bauva @ 2016-03-15 19:24 ` Eric Sunshine 2016-03-15 20:13 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-15 19:24 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 19:24 ` Eric Sunshine @ 2016-03-15 20:13 ` Pranit Bauva 2016-03-15 20:24 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-15 20:13 UTC (permalink / raw) To: Eric Sunshine; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 20:13 ` Pranit Bauva @ 2016-03-15 20:24 ` Junio C Hamano 2016-03-15 21:09 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-15 20:24 UTC (permalink / raw) To: Pranit Bauva; +Cc: Eric Sunshine, SZEDER Gábor, Git List 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. ? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 20:24 ` Junio C Hamano @ 2016-03-15 21:09 ` Pranit Bauva 2016-03-15 21:16 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-15 21:09 UTC (permalink / raw) To: Junio C Hamano; +Cc: Eric Sunshine, SZEDER Gábor, Git List 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? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 21:09 ` Pranit Bauva @ 2016-03-15 21:16 ` Junio C Hamano 2016-03-15 21:18 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-15 21:16 UTC (permalink / raw) To: Pranit Bauva; +Cc: Eric Sunshine, SZEDER Gábor, Git List 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"). ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v7] commit: add a commit.verbose config variable 2016-03-15 21:16 ` Junio C Hamano @ 2016-03-15 21:18 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-15 21:18 UTC (permalink / raw) To: Junio C Hamano; +Cc: Eric Sunshine, SZEDER Gábor, Git List 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! ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-14 21:38 [PATCH v7] commit: add a commit.verbose config variable Pranit Bauva 2016-03-15 11:31 ` SZEDER Gábor @ 2016-03-18 21:19 ` Pranit Bauva 2016-03-18 21:19 ` [PATCH v8 2/2] commit: add a commit.verbose config variable Pranit Bauva 2016-03-18 22:59 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Junio C Hamano 1 sibling, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-18 21:19 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-18 21:19 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva @ 2016-03-18 21:19 ` Pranit Bauva 2016-03-20 3:56 ` Eric Sunshine 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 2016-03-18 22:59 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Junio C Hamano 1 sibling, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-18 21:19 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-18 21:19 ` [PATCH v8 2/2] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-20 3:56 ` Eric Sunshine 2016-03-20 11:05 ` Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-20 3:56 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-20 3:56 ` Eric Sunshine @ 2016-03-20 11:05 ` Pranit Bauva 2016-03-20 17:34 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-20 11:05 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-20 11:05 ` Pranit Bauva @ 2016-03-20 17:34 ` Eric Sunshine 2016-03-20 18:02 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-20 17:34 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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". ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-20 17:34 ` Eric Sunshine @ 2016-03-20 18:02 ` Pranit Bauva 2016-03-23 19:19 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-20 18:02 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-20 18:02 ` Pranit Bauva @ 2016-03-23 19:19 ` Junio C Hamano 2016-03-23 19:23 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-23 19:19 UTC (permalink / raw) To: Pranit Bauva; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-23 19:19 ` Junio C Hamano @ 2016-03-23 19:23 ` Pranit Bauva 2016-03-23 20:43 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-23 19:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 2/2] commit: add a commit.verbose config variable 2016-03-23 19:23 ` Pranit Bauva @ 2016-03-23 20:43 ` Junio C Hamano 0 siblings, 0 replies; 136+ messages in thread From: Junio C Hamano @ 2016-03-23 20:43 UTC (permalink / raw) To: Pranit Bauva; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-18 21:19 ` [PATCH v8 2/2] commit: add a commit.verbose config variable Pranit Bauva 2016-03-20 3:56 ` Eric Sunshine @ 2016-03-24 8:25 ` Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 3/3] commit: add a commit.verbose config variable Pranit Bauva ` (3 more replies) 1 sibling, 4 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-24 8:25 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v9 3/3] commit: add a commit.verbose config variable 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva @ 2016-03-24 8:25 ` Pranit Bauva 2016-03-24 10:04 ` SZEDER Gábor 2016-03-25 0:05 ` Eric Sunshine 2016-03-24 8:25 ` [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script Pranit Bauva ` (2 subsequent siblings) 3 siblings, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-24 8:25 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v9 3/3] commit: add a commit.verbose config variable 2016-03-24 8:25 ` [PATCH v9 3/3] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-24 10:04 ` SZEDER Gábor 2016-03-24 10:22 ` Pranit Bauva 2016-03-25 0:05 ` Eric Sunshine 1 sibling, 1 reply; 136+ messages in thread From: SZEDER Gábor @ 2016-03-24 10:04 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, git > 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 3/3] commit: add a commit.verbose config variable 2016-03-24 10:04 ` SZEDER Gábor @ 2016-03-24 10:22 ` Pranit Bauva 2016-03-24 10:26 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-24 10:22 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 3/3] commit: add a commit.verbose config variable 2016-03-24 10:22 ` Pranit Bauva @ 2016-03-24 10:26 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-24 10:26 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 3/3] commit: add a commit.verbose config variable 2016-03-24 8:25 ` [PATCH v9 3/3] commit: add a commit.verbose config variable Pranit Bauva 2016-03-24 10:04 ` SZEDER Gábor @ 2016-03-25 0:05 ` Eric Sunshine 2016-03-25 6:15 ` Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-25 0:05 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 3/3] commit: add a commit.verbose config variable 2016-03-25 0:05 ` Eric Sunshine @ 2016-03-25 6:15 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-25 6:15 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 3/3] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-24 8:25 ` Pranit Bauva 2016-03-24 11:00 ` SZEDER Gábor 2016-03-24 10:33 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values SZEDER Gábor 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva 3 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-24 8:25 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-24 8:25 ` [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script Pranit Bauva @ 2016-03-24 11:00 ` SZEDER Gábor 2016-03-24 23:57 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: SZEDER Gábor @ 2016-03-24 11:00 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, git > 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 > ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-24 11:00 ` SZEDER Gábor @ 2016-03-24 23:57 ` Eric Sunshine 2016-03-25 6:06 ` Pranit Bauva 2016-03-25 14:46 ` SZEDER Gábor 0 siblings, 2 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-24 23:57 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Pranit Bauva, Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-24 23:57 ` Eric Sunshine @ 2016-03-25 6:06 ` Pranit Bauva 2016-03-25 6:24 ` Eric Sunshine 2016-03-25 14:46 ` SZEDER Gábor 1 sibling, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-25 6:06 UTC (permalink / raw) To: Eric Sunshine; +Cc: SZEDER Gábor, Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-25 6:06 ` Pranit Bauva @ 2016-03-25 6:24 ` Eric Sunshine 2016-03-25 6:55 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-25 6:24 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, Git List 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/ ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-25 6:24 ` Eric Sunshine @ 2016-03-25 6:55 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-25 6:55 UTC (permalink / raw) To: Eric Sunshine; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-24 23:57 ` Eric Sunshine 2016-03-25 6:06 ` Pranit Bauva @ 2016-03-25 14:46 ` SZEDER Gábor 2016-03-25 14:50 ` Pranit Bauva 2016-03-25 17:04 ` Eric Sunshine 1 sibling, 2 replies; 136+ messages in thread From: SZEDER Gábor @ 2016-03-25 14:46 UTC (permalink / raw) To: Eric Sunshine; +Cc: Pranit Bauva, Git List 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'? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-25 14:46 ` SZEDER Gábor @ 2016-03-25 14:50 ` Pranit Bauva 2016-03-25 17:04 ` Eric Sunshine 1 sibling, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-25 14:50 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-25 14:46 ` SZEDER Gábor 2016-03-25 14:50 ` Pranit Bauva @ 2016-03-25 17:04 ` Eric Sunshine 2016-03-25 18:15 ` Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-25 17:04 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Pranit Bauva, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-25 17:04 ` Eric Sunshine @ 2016-03-25 18:15 ` Pranit Bauva 2016-03-25 23:06 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-25 18:15 UTC (permalink / raw) To: Eric Sunshine; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script 2016-03-25 18:15 ` Pranit Bauva @ 2016-03-25 23:06 ` Eric Sunshine 0 siblings, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-25 23:06 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 3/3] commit: add a commit.verbose config variable Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script Pranit Bauva @ 2016-03-24 10:33 ` SZEDER Gábor 2016-03-24 10:38 ` Pranit Bauva ` (2 more replies) 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva 3 siblings, 3 replies; 136+ messages in thread From: SZEDER Gábor @ 2016-03-24 10:33 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, git > 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 > > ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-24 10:33 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values SZEDER Gábor @ 2016-03-24 10:38 ` Pranit Bauva 2016-03-24 23:34 ` Eric Sunshine 2016-03-28 18:42 ` Pranit Bauva 2 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-24 10:38 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List 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 >> >> ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-24 10:33 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values SZEDER Gábor 2016-03-24 10:38 ` Pranit Bauva @ 2016-03-24 23:34 ` Eric Sunshine 2016-03-28 18:42 ` Pranit Bauva 2 siblings, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-24 23:34 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Pranit Bauva, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-24 10:33 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values SZEDER Gábor 2016-03-24 10:38 ` Pranit Bauva 2016-03-24 23:34 ` Eric Sunshine @ 2016-03-28 18:42 ` Pranit Bauva 2016-03-28 19:03 ` Eric Sunshine 2 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-28 18:42 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List > 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-28 18:42 ` Pranit Bauva @ 2016-03-28 19:03 ` Eric Sunshine 0 siblings, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-28 19:03 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva ` (2 preceding siblings ...) 2016-03-24 10:33 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values SZEDER Gábor @ 2016-03-26 19:48 ` Pranit Bauva 2016-03-26 19:48 ` [PATCH v10 3/3] commit: add a commit.verbose config variable Pranit Bauva ` (3 more replies) 3 siblings, 4 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-26 19:48 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva @ 2016-03-26 19:48 ` Pranit Bauva 2016-03-27 3:34 ` Eric Sunshine 2016-03-27 11:51 ` SZEDER Gábor 2016-03-26 19:48 ` [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file Pranit Bauva ` (2 subsequent siblings) 3 siblings, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-26 19:48 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-26 19:48 ` [PATCH v10 3/3] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-27 3:34 ` Eric Sunshine 2016-03-27 7:00 ` Pranit Bauva 2016-03-27 11:51 ` SZEDER Gábor 1 sibling, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 3:34 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 3:34 ` Eric Sunshine @ 2016-03-27 7:00 ` Pranit Bauva 2016-03-27 8:17 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 7:00 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 7:00 ` Pranit Bauva @ 2016-03-27 8:17 ` Eric Sunshine 2016-03-27 8:40 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 8:17 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 8:17 ` Eric Sunshine @ 2016-03-27 8:40 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 8:40 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-26 19:48 ` [PATCH v10 3/3] commit: add a commit.verbose config variable Pranit Bauva 2016-03-27 3:34 ` Eric Sunshine @ 2016-03-27 11:51 ` SZEDER Gábor 2016-03-27 11:59 ` Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: SZEDER Gábor @ 2016-03-27 11:51 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, git > +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 > > ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 11:51 ` SZEDER Gábor @ 2016-03-27 11:59 ` Pranit Bauva 2016-03-27 12:07 ` SZEDER Gábor 2016-03-27 16:48 ` Eric Sunshine 0 siblings, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 11:59 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 11:59 ` Pranit Bauva @ 2016-03-27 12:07 ` SZEDER Gábor 2016-03-27 12:11 ` Pranit Bauva 2016-03-27 16:48 ` Eric Sunshine 1 sibling, 1 reply; 136+ messages in thread From: SZEDER Gábor @ 2016-03-27 12:07 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 12:07 ` SZEDER Gábor @ 2016-03-27 12:11 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 12:11 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 3/3] commit: add a commit.verbose config variable 2016-03-27 11:59 ` Pranit Bauva 2016-03-27 12:07 ` SZEDER Gábor @ 2016-03-27 16:48 ` Eric Sunshine 1 sibling, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 16:48 UTC (permalink / raw) To: Pranit Bauva; +Cc: SZEDER Gábor, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva 2016-03-26 19:48 ` [PATCH v10 3/3] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-26 19:48 ` Pranit Bauva 2016-03-27 3:07 ` Eric Sunshine 2016-03-27 2:45 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Eric Sunshine 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva 3 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-26 19:48 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file 2016-03-26 19:48 ` [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file Pranit Bauva @ 2016-03-27 3:07 ` Eric Sunshine 2016-03-27 13:27 ` SZEDER Gábor [not found] ` <CAFZEwPMaZkUi+DvohhVrc_dW_8cdfJsZX-YA_SRWDp021UvDLQ@mail.gmail.com> 0 siblings, 2 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 3:07 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 > ' ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file 2016-03-27 3:07 ` Eric Sunshine @ 2016-03-27 13:27 ` SZEDER Gábor 2016-03-27 13:43 ` Pranit Bauva 2016-03-27 17:27 ` Eric Sunshine [not found] ` <CAFZEwPMaZkUi+DvohhVrc_dW_8cdfJsZX-YA_SRWDp021UvDLQ@mail.gmail.com> 1 sibling, 2 replies; 136+ messages in thread From: SZEDER Gábor @ 2016-03-27 13:27 UTC (permalink / raw) To: Eric Sunshine; +Cc: SZEDER Gábor, Pranit Bauva, Git List > > +! 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file 2016-03-27 13:27 ` SZEDER Gábor @ 2016-03-27 13:43 ` Pranit Bauva 2016-03-27 17:27 ` Eric Sunshine 1 sibling, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 13:43 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file 2016-03-27 13:27 ` SZEDER Gábor 2016-03-27 13:43 ` Pranit Bauva @ 2016-03-27 17:27 ` Eric Sunshine 2016-03-27 18:31 ` Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 17:27 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Pranit Bauva, Git List 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' ' -- ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file 2016-03-27 17:27 ` Eric Sunshine @ 2016-03-27 18:31 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 18:31 UTC (permalink / raw) To: Eric Sunshine; +Cc: SZEDER Gábor, Git List 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' ' > -- ^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <CAFZEwPMaZkUi+DvohhVrc_dW_8cdfJsZX-YA_SRWDp021UvDLQ@mail.gmail.com>]
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file [not found] ` <CAFZEwPMaZkUi+DvohhVrc_dW_8cdfJsZX-YA_SRWDp021UvDLQ@mail.gmail.com> @ 2016-03-27 17:03 ` Eric Sunshine [not found] ` <CAPig+cTFK=HPAtk7MeMQSTccmiaai++3sVn6J_pRcSi+w_4Lng@mail.gmail.com> 1 sibling, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 17:03 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List, SZEDER Gábor [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 >>> ' ^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <CAPig+cTFK=HPAtk7MeMQSTccmiaai++3sVn6J_pRcSi+w_4Lng@mail.gmail.com>]
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file [not found] ` <CAPig+cTFK=HPAtk7MeMQSTccmiaai++3sVn6J_pRcSi+w_4Lng@mail.gmail.com> @ 2016-03-27 17:05 ` Eric Sunshine [not found] ` <CAFZEwPMJiCTKszfCAVrzsA+jNHwoHPaXySSD3HyiO=f5AikvZg@mail.gmail.com> 1 sibling, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 17:05 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List, SZEDER Gábor [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). ^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <CAFZEwPMJiCTKszfCAVrzsA+jNHwoHPaXySSD3HyiO=f5AikvZg@mail.gmail.com>]
[parent not found: <CAPig+cS3usDDeTMzjqbxqi+k+XbmjawZ0TF20s9-vM6o=Fm=OQ@mail.gmail.com>]
* Re: [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file [not found] ` <CAPig+cS3usDDeTMzjqbxqi+k+XbmjawZ0TF20s9-vM6o=Fm=OQ@mail.gmail.com> @ 2016-03-27 17:08 ` Eric Sunshine 0 siblings, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 17:08 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List, SZEDER Gábor [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). ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva 2016-03-26 19:48 ` [PATCH v10 3/3] commit: add a commit.verbose config variable Pranit Bauva 2016-03-26 19:48 ` [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file Pranit Bauva @ 2016-03-27 2:45 ` Eric Sunshine 2016-03-27 6:10 ` Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva 3 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-03-27 2:45 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values 2016-03-27 2:45 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Eric Sunshine @ 2016-03-27 6:10 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-27 6:10 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v11 1/4] test-parse-options: print quiet as integer 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva ` (2 preceding siblings ...) 2016-03-27 2:45 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Eric Sunshine @ 2016-03-31 14:45 ` Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 4/4] commit: add a commit.verbose config variable Pranit Bauva ` (4 more replies) 3 siblings, 5 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 14:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v11 4/4] commit: add a commit.verbose config variable 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva @ 2016-03-31 14:45 ` Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva ` (3 subsequent siblings) 4 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 14:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 4/4] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-31 14:45 ` Pranit Bauva 2016-03-31 18:41 ` Junio C Hamano 2016-03-31 14:45 ` [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva ` (2 subsequent siblings) 4 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 14:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-03-31 14:45 ` [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-03-31 18:41 ` Junio C Hamano 2016-03-31 19:34 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-31 18:41 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-03-31 18:41 ` Junio C Hamano @ 2016-03-31 19:34 ` Pranit Bauva 2016-03-31 20:06 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 19:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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". ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-03-31 19:34 ` Pranit Bauva @ 2016-03-31 20:06 ` Junio C Hamano 2016-03-31 20:41 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-31 20:06 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-03-31 20:06 ` Junio C Hamano @ 2016-03-31 20:41 ` Pranit Bauva 2016-03-31 20:45 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 20:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-03-31 20:41 ` Pranit Bauva @ 2016-03-31 20:45 ` Junio C Hamano 0 siblings, 0 replies; 136+ messages in thread From: Junio C Hamano @ 2016-03-31 20:45 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 4/4] commit: add a commit.verbose config variable Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-03-31 14:45 ` Pranit Bauva 2016-03-31 18:23 ` Junio C Hamano 2016-03-31 18:19 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Junio C Hamano 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva 4 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 14:45 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-03-31 14:45 ` [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-03-31 18:23 ` Junio C Hamano 2016-03-31 18:42 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-31 18:23 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-03-31 18:23 ` Junio C Hamano @ 2016-03-31 18:42 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 18:42 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 1/4] test-parse-options: print quiet as integer 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva ` (2 preceding siblings ...) 2016-03-31 14:45 ` [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-03-31 18:19 ` Junio C Hamano 2016-03-31 18:40 ` Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva 4 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-31 18:19 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v11 1/4] test-parse-options: print quiet as integer 2016-03-31 18:19 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Junio C Hamano @ 2016-03-31 18:40 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-31 18:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva ` (3 preceding siblings ...) 2016-03-31 18:19 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Junio C Hamano @ 2016-04-02 23:33 ` Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 2/5] test-parse-options: print quiet as integer Pranit Bauva ` (5 more replies) 4 siblings, 6 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-02 23:33 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v12 2/5] test-parse-options: print quiet as integer 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva @ 2016-04-02 23:33 ` Pranit Bauva 2016-04-03 21:30 ` Eric Sunshine 2016-04-02 23:33 ` [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva ` (4 subsequent siblings) 5 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-02 23:33 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v12 2/5] test-parse-options: print quiet as integer 2016-04-02 23:33 ` [PATCH v12 2/5] test-parse-options: print quiet as integer Pranit Bauva @ 2016-04-03 21:30 ` Eric Sunshine 2016-04-05 15:39 ` Pranit Bauva 2016-04-08 16:52 ` Junio C Hamano 0 siblings, 2 replies; 136+ messages in thread From: Eric Sunshine @ 2016-04-03 21:30 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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)"); ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 2/5] test-parse-options: print quiet as integer 2016-04-03 21:30 ` Eric Sunshine @ 2016-04-05 15:39 ` Pranit Bauva 2016-04-06 5:56 ` Eric Sunshine 2016-04-08 11:33 ` Duy Nguyen 2016-04-08 16:52 ` Junio C Hamano 1 sibling, 2 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-05 15:39 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List, Duy Nguyen, jrnieder [+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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 2/5] test-parse-options: print quiet as integer 2016-04-05 15:39 ` Pranit Bauva @ 2016-04-06 5:56 ` Eric Sunshine 2016-04-08 11:33 ` Duy Nguyen 1 sibling, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-04-06 5:56 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List, Duy Nguyen, Jonathan Nieder 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 2/5] test-parse-options: print quiet as integer 2016-04-05 15:39 ` Pranit Bauva 2016-04-06 5:56 ` Eric Sunshine @ 2016-04-08 11:33 ` Duy Nguyen 1 sibling, 0 replies; 136+ messages in thread From: Duy Nguyen @ 2016-04-08 11:33 UTC (permalink / raw) To: Pranit Bauva; +Cc: Eric Sunshine, Git List, Jonathan Nieder 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 2/5] test-parse-options: print quiet as integer 2016-04-03 21:30 ` Eric Sunshine 2016-04-05 15:39 ` Pranit Bauva @ 2016-04-08 16:52 ` Junio C Hamano 1 sibling, 0 replies; 136+ messages in thread From: Junio C Hamano @ 2016-04-08 16:52 UTC (permalink / raw) To: Eric Sunshine; +Cc: Pranit Bauva, Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 2/5] test-parse-options: print quiet as integer Pranit Bauva @ 2016-04-02 23:33 ` Pranit Bauva 2016-04-04 0:02 ` Eric Sunshine 2016-04-02 23:33 ` [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva ` (3 subsequent siblings) 5 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-02 23:33 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-02 23:33 ` [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-04-04 0:02 ` Eric Sunshine 2016-04-04 1:05 ` Eric Sunshine 2016-04-05 15:54 ` Pranit Bauva 0 siblings, 2 replies; 136+ messages in thread From: Eric Sunshine @ 2016-04-04 0:02 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 > ' ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-04 0:02 ` Eric Sunshine @ 2016-04-04 1:05 ` Eric Sunshine 2016-04-05 15:54 ` Pranit Bauva 1 sibling, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-04-04 1:05 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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'"). ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-04 0:02 ` Eric Sunshine 2016-04-04 1:05 ` Eric Sunshine @ 2016-04-05 15:54 ` Pranit Bauva 1 sibling, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-05 15:54 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 >> ' ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 2/5] test-parse-options: print quiet as integer Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-04-02 23:33 ` Pranit Bauva 2016-04-03 23:10 ` Eric Sunshine 2016-04-02 23:33 ` [PATCH v12 5/5] commit: add a commit.verbose config variable Pranit Bauva ` (2 subsequent siblings) 5 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-02 23:33 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-02 23:33 ` [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-04-03 23:10 ` Eric Sunshine 2016-04-05 15:51 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-03 23:10 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-03 23:10 ` Eric Sunshine @ 2016-04-05 15:51 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-05 15:51 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v12 5/5] commit: add a commit.verbose config variable 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva ` (2 preceding siblings ...) 2016-04-02 23:33 ` [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-04-02 23:33 ` Pranit Bauva 2016-04-04 0:58 ` Eric Sunshine 2016-04-03 21:00 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Eric Sunshine 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva 5 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-02 23:33 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v12 5/5] commit: add a commit.verbose config variable 2016-04-02 23:33 ` [PATCH v12 5/5] commit: add a commit.verbose config variable Pranit Bauva @ 2016-04-04 0:58 ` Eric Sunshine 2016-04-04 23:29 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-04 0:58 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 5/5] commit: add a commit.verbose config variable 2016-04-04 0:58 ` Eric Sunshine @ 2016-04-04 23:29 ` Eric Sunshine 2016-04-05 15:58 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-04 23:29 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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.) ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 5/5] commit: add a commit.verbose config variable 2016-04-04 23:29 ` Eric Sunshine @ 2016-04-05 15:58 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-05 15:58 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva ` (3 preceding siblings ...) 2016-04-02 23:33 ` [PATCH v12 5/5] commit: add a commit.verbose config variable Pranit Bauva @ 2016-04-03 21:00 ` Eric Sunshine 2016-04-04 12:45 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva 5 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-03 21:00 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues 2016-04-03 21:00 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Eric Sunshine @ 2016-04-04 12:45 ` Pranit Bauva 2016-04-04 17:30 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-04 12:45 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues 2016-04-04 12:45 ` Pranit Bauva @ 2016-04-04 17:30 ` Eric Sunshine 2016-04-05 5:08 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-04 17:30 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues 2016-04-04 17:30 ` Eric Sunshine @ 2016-04-05 5:08 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-05 5:08 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. :) ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v13 1/6] t0040-test-parse-options.sh: fix style issues 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva ` (4 preceding siblings ...) 2016-04-03 21:00 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Eric Sunshine @ 2016-04-09 12:23 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 3/6] t0040-parse-options: improve test coverage Pranit Bauva ` (5 more replies) 5 siblings, 6 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-09 12:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v13 3/6] t0040-parse-options: improve test coverage 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva @ 2016-04-09 12:23 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva ` (4 subsequent siblings) 5 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-09 12:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v13 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 3/6] t0040-parse-options: improve test coverage Pranit Bauva @ 2016-04-09 12:23 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva ` (3 subsequent siblings) 5 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-09 12:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v13 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 3/6] t0040-parse-options: improve test coverage Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-04-09 12:23 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 6/6] commit: add a commit.verbose config variable Pranit Bauva ` (2 subsequent siblings) 5 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-09 12:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v13 6/6] commit: add a commit.verbose config variable 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva ` (2 preceding siblings ...) 2016-04-09 12:23 ` [PATCH v13 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-04-09 12:23 ` Pranit Bauva 2016-04-12 21:24 ` Junio C Hamano 2016-04-09 12:23 ` [PATCH v13 2/6] test-parse-options: print quiet as integer Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva 5 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-09 12:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v13 6/6] commit: add a commit.verbose config variable 2016-04-09 12:23 ` [PATCH v13 6/6] commit: add a commit.verbose config variable Pranit Bauva @ 2016-04-12 21:24 ` Junio C Hamano 2016-04-12 21:28 ` Pranit Bauva 2016-04-12 21:39 ` Junio C Hamano 0 siblings, 2 replies; 136+ messages in thread From: Junio C Hamano @ 2016-04-12 21:24 UTC (permalink / raw) To: Pranit Bauva; +Cc: git Hmph, isn't this already in 'next', hence we cannot accept a replacement patch? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v13 6/6] commit: add a commit.verbose config variable 2016-04-12 21:24 ` Junio C Hamano @ 2016-04-12 21:28 ` Pranit Bauva 2016-04-12 21:39 ` Junio C Hamano 1 sibling, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 21:28 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v13 6/6] commit: add a commit.verbose config variable 2016-04-12 21:24 ` Junio C Hamano 2016-04-12 21:28 ` Pranit Bauva @ 2016-04-12 21:39 ` Junio C Hamano 2016-04-12 22:18 ` Junio C Hamano 1 sibling, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-04-12 21:39 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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'. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v13 6/6] commit: add a commit.verbose config variable 2016-04-12 21:39 ` Junio C Hamano @ 2016-04-12 22:18 ` Junio C Hamano 2016-04-12 22:25 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-04-12 22:18 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v13 6/6] commit: add a commit.verbose config variable 2016-04-12 22:18 ` Junio C Hamano @ 2016-04-12 22:25 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 22:25 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v13 2/6] test-parse-options: print quiet as integer 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva ` (3 preceding siblings ...) 2016-04-09 12:23 ` [PATCH v13 6/6] commit: add a commit.verbose config variable Pranit Bauva @ 2016-04-09 12:23 ` Pranit Bauva 2016-04-12 21:33 ` Junio C Hamano 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva 5 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-09 12:23 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v13 2/6] test-parse-options: print quiet as integer 2016-04-09 12:23 ` [PATCH v13 2/6] test-parse-options: print quiet as integer Pranit Bauva @ 2016-04-12 21:33 ` Junio C Hamano 2016-04-12 22:16 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-04-12 21:33 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v13 2/6] test-parse-options: print quiet as integer 2016-04-12 21:33 ` Junio C Hamano @ 2016-04-12 22:16 ` Pranit Bauva 2016-04-12 23:11 ` Junio C Hamano 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 22:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v13 2/6] test-parse-options: print quiet as integer 2016-04-12 22:16 ` Pranit Bauva @ 2016-04-12 23:11 ` Junio C Hamano 0 siblings, 0 replies; 136+ messages in thread From: Junio C Hamano @ 2016-04-12 23:11 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva ` (4 preceding siblings ...) 2016-04-09 12:23 ` [PATCH v13 2/6] test-parse-options: print quiet as integer Pranit Bauva @ 2016-04-12 23:02 ` Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva ` (4 more replies) 5 siblings, 5 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 23:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva @ 2016-04-12 23:02 ` Pranit Bauva 2016-04-13 5:56 ` Eric Sunshine 2016-04-12 23:02 ` [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva ` (3 subsequent siblings) 4 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 23:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-12 23:02 ` [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-04-13 5:56 ` Eric Sunshine 2016-04-13 8:39 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 5:56 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-13 5:56 ` Eric Sunshine @ 2016-04-13 8:39 ` Pranit Bauva 2016-04-13 17:33 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-13 8:39 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-13 8:39 ` Pranit Bauva @ 2016-04-13 17:33 ` Eric Sunshine 2016-04-13 17:43 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 17:33 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-13 17:33 ` Eric Sunshine @ 2016-04-13 17:43 ` Pranit Bauva 2016-04-13 17:50 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-13 17:43 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values 2016-04-13 17:43 ` Pranit Bauva @ 2016-04-13 17:50 ` Eric Sunshine 0 siblings, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 17:50 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva @ 2016-04-12 23:02 ` Pranit Bauva 2016-04-13 6:03 ` Eric Sunshine 2016-04-12 23:02 ` [PATCH v14 3/6] t0040-parse-options: improve test coverage Pranit Bauva ` (2 subsequent siblings) 4 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 23:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-12 23:02 ` [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-04-13 6:03 ` Eric Sunshine 2016-04-13 9:00 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 6:03 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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> ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs 2016-04-13 6:03 ` Eric Sunshine @ 2016-04-13 9:00 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-13 9:00 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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> ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva @ 2016-04-12 23:02 ` Pranit Bauva 2016-04-13 5:26 ` Eric Sunshine 2016-04-12 23:02 ` [PATCH v14 6/6] commit: add a commit.verbose config variable Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 2/6] test-parse-options: print quiet as integer Pranit Bauva 4 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 23:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-12 23:02 ` [PATCH v14 3/6] t0040-parse-options: improve test coverage Pranit Bauva @ 2016-04-13 5:26 ` Eric Sunshine 2016-04-13 8:59 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 5:26 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-13 5:26 ` Eric Sunshine @ 2016-04-13 8:59 ` Pranit Bauva 2016-04-13 17:27 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-13 8:59 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-13 8:59 ` Pranit Bauva @ 2016-04-13 17:27 ` Eric Sunshine 2016-04-25 18:40 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 17:27 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-13 17:27 ` Eric Sunshine @ 2016-04-25 18:40 ` Pranit Bauva 2016-04-27 17:55 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-25 18:40 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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? ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-25 18:40 ` Pranit Bauva @ 2016-04-27 17:55 ` Eric Sunshine 2016-04-27 18:16 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-27 17:55 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 3/6] t0040-parse-options: improve test coverage 2016-04-27 17:55 ` Eric Sunshine @ 2016-04-27 18:16 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-27 18:16 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v14 6/6] commit: add a commit.verbose config variable 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva ` (2 preceding siblings ...) 2016-04-12 23:02 ` [PATCH v14 3/6] t0040-parse-options: improve test coverage Pranit Bauva @ 2016-04-12 23:02 ` Pranit Bauva 2016-04-13 6:14 ` Eric Sunshine 2016-04-12 23:02 ` [PATCH v14 2/6] test-parse-options: print quiet as integer Pranit Bauva 4 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 23:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v14 6/6] commit: add a commit.verbose config variable 2016-04-12 23:02 ` [PATCH v14 6/6] commit: add a commit.verbose config variable Pranit Bauva @ 2016-04-13 6:14 ` Eric Sunshine 2016-04-13 9:15 ` Pranit Bauva 0 siblings, 1 reply; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 6:14 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 6/6] commit: add a commit.verbose config variable 2016-04-13 6:14 ` Eric Sunshine @ 2016-04-13 9:15 ` Pranit Bauva 2016-04-13 17:44 ` Eric Sunshine 0 siblings, 1 reply; 136+ messages in thread From: Pranit Bauva @ 2016-04-13 9:15 UTC (permalink / raw) To: Eric Sunshine; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v14 6/6] commit: add a commit.verbose config variable 2016-04-13 9:15 ` Pranit Bauva @ 2016-04-13 17:44 ` Eric Sunshine 0 siblings, 0 replies; 136+ messages in thread From: Eric Sunshine @ 2016-04-13 17:44 UTC (permalink / raw) To: Pranit Bauva; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v14 2/6] test-parse-options: print quiet as integer 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva ` (3 preceding siblings ...) 2016-04-12 23:02 ` [PATCH v14 6/6] commit: add a commit.verbose config variable Pranit Bauva @ 2016-04-12 23:02 ` Pranit Bauva 4 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-04-12 23:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-18 21:19 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 2016-03-18 21:19 ` [PATCH v8 2/2] commit: add a commit.verbose config variable Pranit Bauva @ 2016-03-18 22:59 ` Junio C Hamano 2016-03-19 4:55 ` Pranit Bauva 1 sibling, 1 reply; 136+ messages in thread From: Junio C Hamano @ 2016-03-18 22:59 UTC (permalink / raw) To: Pranit Bauva; +Cc: git 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values 2016-03-18 22:59 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Junio C Hamano @ 2016-03-19 4:55 ` Pranit Bauva 0 siblings, 0 replies; 136+ messages in thread From: Pranit Bauva @ 2016-03-19 4:55 UTC (permalink / raw) To: Junio C Hamano; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 136+ messages in thread
end of thread, other threads:[~2016-04-27 18:16 UTC | newest] Thread overview: 136+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-14 21:38 [PATCH v7] commit: add a commit.verbose config variable Pranit Bauva 2016-03-15 11:31 ` SZEDER Gábor 2016-03-15 19:00 ` Pranit Bauva 2016-03-15 19:24 ` Eric Sunshine 2016-03-15 20:13 ` Pranit Bauva 2016-03-15 20:24 ` Junio C Hamano 2016-03-15 21:09 ` Pranit Bauva 2016-03-15 21:16 ` Junio C Hamano 2016-03-15 21:18 ` Pranit Bauva 2016-03-18 21:19 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 2016-03-18 21:19 ` [PATCH v8 2/2] commit: add a commit.verbose config variable Pranit Bauva 2016-03-20 3:56 ` Eric Sunshine 2016-03-20 11:05 ` Pranit Bauva 2016-03-20 17:34 ` Eric Sunshine 2016-03-20 18:02 ` Pranit Bauva 2016-03-23 19:19 ` Junio C Hamano 2016-03-23 19:23 ` Pranit Bauva 2016-03-23 20:43 ` Junio C Hamano 2016-03-24 8:25 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 3/3] commit: add a commit.verbose config variable Pranit Bauva 2016-03-24 10:04 ` SZEDER Gábor 2016-03-24 10:22 ` Pranit Bauva 2016-03-24 10:26 ` Pranit Bauva 2016-03-25 0:05 ` Eric Sunshine 2016-03-25 6:15 ` Pranit Bauva 2016-03-24 8:25 ` [PATCH v9 2/3] t7507-commit-verbose: make test suite use write_script Pranit Bauva 2016-03-24 11:00 ` SZEDER Gábor 2016-03-24 23:57 ` Eric Sunshine 2016-03-25 6:06 ` Pranit Bauva 2016-03-25 6:24 ` Eric Sunshine 2016-03-25 6:55 ` Pranit Bauva 2016-03-25 14:46 ` SZEDER Gábor 2016-03-25 14:50 ` Pranit Bauva 2016-03-25 17:04 ` Eric Sunshine 2016-03-25 18:15 ` Pranit Bauva 2016-03-25 23:06 ` Eric Sunshine 2016-03-24 10:33 ` [PATCH v9 1/3] parse-options.c: make OPTION__COUNTUP consider negative values SZEDER Gábor 2016-03-24 10:38 ` Pranit Bauva 2016-03-24 23:34 ` Eric Sunshine 2016-03-28 18:42 ` Pranit Bauva 2016-03-28 19:03 ` Eric Sunshine 2016-03-26 19:48 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Pranit Bauva 2016-03-26 19:48 ` [PATCH v10 3/3] commit: add a commit.verbose config variable Pranit Bauva 2016-03-27 3:34 ` Eric Sunshine 2016-03-27 7:00 ` Pranit Bauva 2016-03-27 8:17 ` Eric Sunshine 2016-03-27 8:40 ` Pranit Bauva 2016-03-27 11:51 ` SZEDER Gábor 2016-03-27 11:59 ` Pranit Bauva 2016-03-27 12:07 ` SZEDER Gábor 2016-03-27 12:11 ` Pranit Bauva 2016-03-27 16:48 ` Eric Sunshine 2016-03-26 19:48 ` [PATCH v10 2/3] t7507-commit-verbose: store output of grep in a file Pranit Bauva 2016-03-27 3:07 ` Eric Sunshine 2016-03-27 13:27 ` SZEDER Gábor 2016-03-27 13:43 ` Pranit Bauva 2016-03-27 17:27 ` Eric Sunshine 2016-03-27 18:31 ` Pranit Bauva [not found] ` <CAFZEwPMaZkUi+DvohhVrc_dW_8cdfJsZX-YA_SRWDp021UvDLQ@mail.gmail.com> 2016-03-27 17:03 ` Eric Sunshine [not found] ` <CAPig+cTFK=HPAtk7MeMQSTccmiaai++3sVn6J_pRcSi+w_4Lng@mail.gmail.com> 2016-03-27 17:05 ` Eric Sunshine [not found] ` <CAFZEwPMJiCTKszfCAVrzsA+jNHwoHPaXySSD3HyiO=f5AikvZg@mail.gmail.com> [not found] ` <CAPig+cS3usDDeTMzjqbxqi+k+XbmjawZ0TF20s9-vM6o=Fm=OQ@mail.gmail.com> 2016-03-27 17:08 ` Eric Sunshine 2016-03-27 2:45 ` [PATCH v10 1/3] parse-options.c: make OPTION__COUNTUP understand "unspecified" values Eric Sunshine 2016-03-27 6:10 ` Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 4/4] commit: add a commit.verbose config variable Pranit Bauva 2016-03-31 14:45 ` [PATCH v11 2/4] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva 2016-03-31 18:41 ` Junio C Hamano 2016-03-31 19:34 ` Pranit Bauva 2016-03-31 20:06 ` Junio C Hamano 2016-03-31 20:41 ` Pranit Bauva 2016-03-31 20:45 ` Junio C Hamano 2016-03-31 14:45 ` [PATCH v11 3/4] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva 2016-03-31 18:23 ` Junio C Hamano 2016-03-31 18:42 ` Pranit Bauva 2016-03-31 18:19 ` [PATCH v11 1/4] test-parse-options: print quiet as integer Junio C Hamano 2016-03-31 18:40 ` Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 2/5] test-parse-options: print quiet as integer Pranit Bauva 2016-04-03 21:30 ` Eric Sunshine 2016-04-05 15:39 ` Pranit Bauva 2016-04-06 5:56 ` Eric Sunshine 2016-04-08 11:33 ` Duy Nguyen 2016-04-08 16:52 ` Junio C Hamano 2016-04-02 23:33 ` [PATCH v12 4/5] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva 2016-04-04 0:02 ` Eric Sunshine 2016-04-04 1:05 ` Eric Sunshine 2016-04-05 15:54 ` Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 3/5] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva 2016-04-03 23:10 ` Eric Sunshine 2016-04-05 15:51 ` Pranit Bauva 2016-04-02 23:33 ` [PATCH v12 5/5] commit: add a commit.verbose config variable Pranit Bauva 2016-04-04 0:58 ` Eric Sunshine 2016-04-04 23:29 ` Eric Sunshine 2016-04-05 15:58 ` Pranit Bauva 2016-04-03 21:00 ` [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues Eric Sunshine 2016-04-04 12:45 ` Pranit Bauva 2016-04-04 17:30 ` Eric Sunshine 2016-04-05 5:08 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 1/6] " Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 3/6] t0040-parse-options: improve test coverage Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 6/6] commit: add a commit.verbose config variable Pranit Bauva 2016-04-12 21:24 ` Junio C Hamano 2016-04-12 21:28 ` Pranit Bauva 2016-04-12 21:39 ` Junio C Hamano 2016-04-12 22:18 ` Junio C Hamano 2016-04-12 22:25 ` Pranit Bauva 2016-04-09 12:23 ` [PATCH v13 2/6] test-parse-options: print quiet as integer Pranit Bauva 2016-04-12 21:33 ` Junio C Hamano 2016-04-12 22:16 ` Pranit Bauva 2016-04-12 23:11 ` Junio C Hamano 2016-04-12 23:02 ` [PATCH v14 1/6] t0040-test-parse-options.sh: fix style issues Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 4/6] parse-options.c: make OPTION_COUNTUP respect "unspecified" values Pranit Bauva 2016-04-13 5:56 ` Eric Sunshine 2016-04-13 8:39 ` Pranit Bauva 2016-04-13 17:33 ` Eric Sunshine 2016-04-13 17:43 ` Pranit Bauva 2016-04-13 17:50 ` Eric Sunshine 2016-04-12 23:02 ` [PATCH v14 5/6] t7507-commit-verbose: improve test coverage by testing number of diffs Pranit Bauva 2016-04-13 6:03 ` Eric Sunshine 2016-04-13 9:00 ` Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 3/6] t0040-parse-options: improve test coverage Pranit Bauva 2016-04-13 5:26 ` Eric Sunshine 2016-04-13 8:59 ` Pranit Bauva 2016-04-13 17:27 ` Eric Sunshine 2016-04-25 18:40 ` Pranit Bauva 2016-04-27 17:55 ` Eric Sunshine 2016-04-27 18:16 ` Pranit Bauva 2016-04-12 23:02 ` [PATCH v14 6/6] commit: add a commit.verbose config variable Pranit Bauva 2016-04-13 6:14 ` Eric Sunshine 2016-04-13 9:15 ` Pranit Bauva 2016-04-13 17:44 ` Eric Sunshine 2016-04-12 23:02 ` [PATCH v14 2/6] test-parse-options: print quiet as integer Pranit Bauva 2016-03-18 22:59 ` [PATCH v8 1/2] parse-options.c: make OPTION__COUNTUP consider negative values Junio C Hamano 2016-03-19 4:55 ` Pranit Bauva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).