Re: [PATCH v2] range-diff: add a --no-patch option to show a summary

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> diff --git a/builtin/range-diff.c b/builtin/range-diff.c
> index f01a0be851..05d1f6b6b6 100644
> --- a/builtin/range-diff.c
> +++ b/builtin/range-diff.c
> @@ -16,11 +16,14 @@ int cmd_range_diff(int argc, const char **argv, const char *prefix)
>  	int creation_factor = RANGE_DIFF_CREATION_FACTOR_DEFAULT;
>  	struct diff_options diffopt = { NULL };
>  	int simple_color = -1;
> +	int no_patch = 0;
>  	struct option options[] = {
>  		OPT_INTEGER(0, "creation-factor", &creation_factor,
>  			    N_("Percentage by which creation is weighted")),
>  		OPT_BOOL(0, "no-dual-color", &simple_color,
>  			    N_("use simple diff colors")),
> +		OPT_BOOL_F('s', "no-patch", &no_patch,
> +			 N_("show patch output"), PARSE_OPT_NONEG),

As OPT_BOOL("patch") natively takes "--no-patch" to flip the bool
off, an int variable "patch" that is initialized to 1 would make it
more readable by avoiding double negation !no_patch like the one we
see below.  I guess the reason behind the contortion you wanted to
give the synonym --silent to it?

> @@ -92,7 +95,7 @@ int cmd_range_diff(int argc, const char **argv, const char *prefix)
>  	}
>  
>  	res = show_range_diff(range1.buf, range2.buf, creation_factor,
> -			      simple_color < 1, &diffopt);
> +			      simple_color < 1, !no_patch, &diffopt);

>  	strbuf_release(&range1);
>  	strbuf_release(&range2);

> @@ -7,6 +7,7 @@
>  
>  int show_range_diff(const char *range1, const char *range2,
>  		    int creation_factor, int dual_color,
> +		    int patch,
>  		    struct diff_options *diffopt);

Other than that small "Huh?", the code looks good to me.

> diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
> index 6aae364171..27e071650b 100755
> --- a/t/t3206-range-diff.sh
> +++ b/t/t3206-range-diff.sh
> @@ -122,6 +122,26 @@ test_expect_success 'changed commit' '
>  	test_cmp expected actual
>  '
>  
> +test_expect_success 'changed commit -p & --patch' '
> +	git range-diff --no-color -p topic...changed >actual &&
> +	test_cmp expected actual &&
> +	git range-diff --no-color --patch topic...changed >actual &&
> +	test_cmp expected actual

This makes sure that -p and --patch produces the same output as the
default case?  I am not sure who in the parseopt API groks the
single letter "-p" in this case offhand.  Care to explain how?

The other side of the test to see -s/--no-patch we see below also
makes sense.

> +test_expect_success 'changed commit -s & --no-patch' '
> +...
> +	cat >expected <<-EOF &&

Quote EOF to allow readers skim the contents without looking for and
worrying about $substitutions in there, unless there are tons of
offending code in the same script already in which case we should
leave the clean-up outside this primary change.