[Outreachy] advice: revamp advise API

[HebaWaly]

V7:

• Back to the enum approach.
• Cache enabled values in advice_setting array.
• Although an approach was suggested to get rid of
  the switch case in advice_enabled(), it is kept because
  it'll be needed when handling other special cases e.g:
  ADVICE_ GRAFT_FILE_DEPRECATED.

---

In V6:

• Replace the enum approach by const char arrays.
• Fix camelCase name for one of the config variables.

---

Main changes in V4:

• Re-order the commits.
• Free the output after using xstrfmt().

---

Changes in V3:

• Remove the new wrapper advice_push_update_rejected_enabled() (which was added in V2 to handle a special case of having a config variable alias), and replace it by adding switch cases to advice_enabled() (The reason behind this change is that another special case came up while I was migrating the rest of the advise calls to the new APIs.)
• Remove trailing whitespaces.

---

Main changes in V2:

• Rename advise_ng to advise_if_enabled.
• Add a new advise_enabled() helper.
• Add a list of config variables names to replace advice_config[] (used by list_config_advices()).
• Send an enum parameter to the new advise helpers instead of strings.
• Extract vadvise() from advise() and advise_if enabled().

---

The advice API is currently a little bit confusing to call.
quoting from [1]:

When introducing a new advice message, you would

 * come up with advice.frotz configuration variable

 * define and declare advice_frotz global variable that defaults to
   true

 * sprinkle calls like this:

  if (advice_frotz)
    advise(_("helpful message about frotz"));

A new approach was suggested in [1] which this patch is based upon.

A new advise_if_enabled() is introduced to gradually replace advise()
advice_enabled() helper is also introduced to be used by those callers who:

• Only need to check the visibility without calling advise() (they call die() or error() instead for example)
• Need to carry out some heavy processing to display an advice, in this case they'll do:
  if(advice_enabled(advice_type))
  advise("some advice message");

To introduce a new advice message, the caller needs to:

• Define a new advice_type enum.
• Come up with a new config variable name and add this name to advice_setting[]
• Call advise_if_enabled(new_advice_type, "advice message to be printed")
• Or call advice_enabled(new_advice_type) first and then follow it by advise("advice message to be printed") as explained earlier.
• Add the new config variable to Documentation/config/advice.txt

The reason a new list of configuration variables was added to the library is to be used by the list_config_advices() function instead of advice_config[].
And we should get rid of advice_config[] once we migrate all the callers to use the new APIs instead of checking the global variables (which we'll get rid of as well).

In the future, we can investigate generating the documentation from the list of config variables or vice versa to make introducing a new advice much easier, but this approach will do it for now.

V2 makes the process of introducing a new advice longer than V1 and almost as long as the original library, but having the advice library responsible for checking the message visibility is still an improvement and in my own opinion the new structure makes better sense and makes the library less confusing to use.

After this patch the plan is to change the advise() calls to advise_if_enabled() whenever possible, or at least replace the global variables checks by advise_enabled() when advise_if_enabled() is not suitable.

[1] https://public-inbox.org/git/[email protected]/

[HebaWaly]

/submit

[gitgitgadget]

Submitted as [email protected]

[gitgitgadget]

On the Git mailing list, Derrick Stolee wrote (reply to this):

On 2/10/2020 12:04 AM, Heba Waly via GitGitGadget wrote:
> From: Heba Waly <[email protected]>
> 
> Add a new advise_ng function that can check the visibility of advice
> messages before printing.
>
> Currently it's very easy for the callers to miss checking the
> visibility step. Also, it makes more sense for this step to be handled
> by the advice library.

This makes the advice API much easier and its uses much cleaner. Thanks!
 
> Also change the advise call in tag library from advise() to advise_ng()
> to construct an example of the usage of the new API.

This is a good example case.

> +static const char turn_off_instructions[] =
> +N_("\n"
> +"Turn this message off by running\n"
> +"\"git config %s false\"");

I have mixed feelings on the use of these instructions. Perhaps at
minimum the addition of these instructions could be left to a
separate patch than the creation of advise_ng().

My biggest concern is that this adds unexpected noise to users who
want the advice to stay. I'm calling attention to it, because this
part isn't a simple refactor like the rest of the patch.

If it _does_ stay, then I recommend condensing the message to
a single line. For example:

	Disable this message with "git config %d false"

> +void advise_ng(const char *key, const char *advice, ...)
> +{
> +	int value = 1;
> +	struct strbuf buf = STRBUF_INIT;
> +	va_list params;
> +	const char *cp, *np;
> +	
> +	git_config_get_bool(key, &value);
> +	
> +	if(value)
> +	{

Style: spacing, and opening braces are on the same line as the if:

	if (value) {

But also, this method would be simpler if the opposite case was
an early return:

	if (!value)
		return;

Then the rest could have one less indentation.

> +		va_start(params, advice);
> +		strbuf_vaddf(&buf, advice, params);
> +		va_end(params);
> +
> +		strbuf_addf(&buf, turn_off_instructions, key);
> +
> +		for (cp = buf.buf; *cp; cp = np) {
> +			np = strchrnul(cp, '\n');
> +			fprintf(stderr,	_("%shint: %.*s%s\n"),
> +				advise_get_color(ADVICE_COLOR_HINT),
> +				(int)(np - cp), cp,
> +				advise_get_color(ADVICE_COLOR_RESET));
> +			if (*np)
> +				np++;
> +		}
> +		strbuf_release(&buf);

This loop looks like it was copied from advise(). Perhaps we could
re-use that code better by creating a new vadvise() method that
takes a va_list, and have advise() and advise_ng() call it instead?
I include a patch at the end of this method that does this conversion.
(Feel free to incorporate it into your next version, if you want, but
be sure to add your sign-off.) Then, your advise_ng() can call these:

	vadvise(advice, params);
	advise(turn_off_instructions, key);

removing the need to re-implement the for loop.

> diff --git a/t/helper/test-advise.c b/t/helper/test-advise.c
> new file mode 100644
> index 0000000000..b6ec90fd18
> --- /dev/null
> +++ b/t/helper/test-advise.c
> @@ -0,0 +1,15 @@
> +#include "test-tool.h"
> +#include "cache.h"
> +#include "advice.h"
> +
> +int cmd__advise_ng(int argc, const char **argv)
> +{
> +	if (!argv[1] || !argv[2])
> +	die("usage: %s <key> <advice>", argv[0]);
> +
> +	setup_git_directory();
> +
> +	advise_ng(argv[1], argv[2]);
> +
> +	return 0;
> +}

I definitely tend to recommend more tests than most, but perhaps this
unit test is overkill? You demonstrate a good test below using a real
Git command, which should be sufficient. If the "turn this message off"
part gets removed, then you will still have coverage of your method.
It just won't require a test change because it would not modify behavior.

> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 6db92bd3ba..b7c8d41899 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1726,6 +1726,8 @@ test_expect_success 'recursive tagging should give advice' '
>  	hint: already a tag. If you meant to tag the object that it points to, use:
>  	hint: |
>  	hint: 	git tag -f nested annotated-v4.0^{}
> +	hint: Turn this message off by running
> +	hint: "git config advice.nestedTag false"
>  	EOF
>  	git tag -m nested nested annotated-v4.0 2>actual &&
>  	test_i18ncmp expect actual
> 
> base-commit: c7a62075917b3340f908093f63f1161c44ed1475

Thanks,
-Stolee

-->8--

From: Derrick Stolee <[email protected]>
Date: Mon, 10 Feb 2020 09:33:20 -0500
Subject: [PATCH] advice: extract vadvise() from advise()

In preparation for a new advice method, extract a version of advise()
that uses an explict 'va_list' parameter. Call it from advise() for a
functionally equivalent version.

Signed-off-by: Derrick Stolee <[email protected]>
---
 advice.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/advice.c b/advice.c
index 249c60dcf3..fd836332da 100644
--- a/advice.c
+++ b/advice.c
@@ -96,15 +96,12 @@ static struct {
 	{ "pushNonFastForward", &advice_push_update_rejected }
 };
 
-void advise(const char *advice, ...)
+static void vadvise(const char *advice, va_list params)
 {
 	struct strbuf buf = STRBUF_INIT;
-	va_list params;
 	const char *cp, *np;
 
-	va_start(params, advice);
 	strbuf_vaddf(&buf, advice, params);
-	va_end(params);
 
 	for (cp = buf.buf; *cp; cp = np) {
 		np = strchrnul(cp, '\n');
@@ -118,6 +115,14 @@ void advise(const char *advice, ...)
 	strbuf_release(&buf);
 }
 
+void advise(const char *advice, ...)
+{
+	va_list params;
+	va_start(params, advice);
+	vadvise(advice, params);
+	va_end(params);
+}
+
 int git_default_advice_config(const char *var, const char *value)
 {
 	const char *k, *slot_name;
-- 
2.25.0.vfs.1.1.1.g9906319d24.dirty

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

Derrick Stolee <[email protected]> writes:

>> +static const char turn_off_instructions[] =
>> +N_("\n"
>> +"Turn this message off by running\n"
>> +"\"git config %s false\"");
>
> I have mixed feelings on the use of these instructions. Perhaps at
> minimum the addition of these instructions could be left to a
> separate patch than the creation of advise_ng().
>
> My biggest concern is that this adds unexpected noise to users who
> want the advice to stay. I'm calling attention to it, because this
> part isn't a simple refactor like the rest of the patch.
> ...
> I definitely tend to recommend more tests than most, but perhaps this
> unit test is overkill? You demonstrate a good test below using a real
> Git command, which should be sufficient. If the "turn this message off"
> part gets removed, then you will still have coverage of your method.
> It just won't require a test change because it would not modify behavior.
> ...

All good suggestions.  Thanks for an excellent review.

Another thing.  

advise_ng() may have been a good name for illustration but is a
horrible name for real-world use (imagine we need to revamp the API
one more time in the future---what would it be called, which has to
say that it is newer than the "next generation"?
advise_3rd_try()?).

Thanks.

[gitgitgadget]

On the Git mailing list, Taylor Blau wrote (reply to this):

On Mon, Feb 10, 2020 at 11:30:46AM -0800, Junio C Hamano wrote:
> Derrick Stolee <[email protected]> writes:
>
> >> +static const char turn_off_instructions[] =
> >> +N_("\n"
> >> +"Turn this message off by running\n"
> >> +"\"git config %s false\"");
> >
> > I have mixed feelings on the use of these instructions. Perhaps at
> > minimum the addition of these instructions could be left to a
> > separate patch than the creation of advise_ng().
> >
> > My biggest concern is that this adds unexpected noise to users who
> > want the advice to stay. I'm calling attention to it, because this
> > part isn't a simple refactor like the rest of the patch.
> > ...
> > I definitely tend to recommend more tests than most, but perhaps this
> > unit test is overkill? You demonstrate a good test below using a real
> > Git command, which should be sufficient. If the "turn this message off"
> > part gets removed, then you will still have coverage of your method.
> > It just won't require a test change because it would not modify behavior.
> > ...
>
> All good suggestions.  Thanks for an excellent review.
>
> Another thing.
>
> advise_ng() may have been a good name for illustration but is a
> horrible name for real-world use (imagine we need to revamp the API
> one more time in the future---what would it be called, which has to
> say that it is newer than the "next generation"?
> advise_3rd_try()?).

What about calling this new API 'advise()'? The first patch could call
it 'advise_ng' or whatever other temporary name we feel comfortable
using, and then each subsequent patch would update callers of 'advise()'
to use 'advise_ng()'. Once those patches have been applied, and no other
callers of 'advise()' exist, a final patch can be applied on top to
rename 'advise_ng()' to 'advise()', and update the names of all of the
callers.

This makes for a rather noisy final patch, but the intermediate states
are much clearer, and it would make this series rather self-contained.

On the other hand, having a version of 'advise_ng()' on master makes
this topic more incremental, meaning that we can pick it up and put it
down at ease and have more self-contained projects.

I don't really have a preference between the two approaches, but if we
go with the latter, I do think we need something better than
'advise_ng'. Maybe 'advise_warn'? I don't know.

> Thanks.

Thanks,
Taylor

[gitgitgadget]

On the Git mailing list, Jeff King wrote (reply to this):

On Mon, Feb 10, 2020 at 05:04:09AM +0000, Heba Waly via GitGitGadget wrote:

>     The advice API is currently a little bit confusing to call. quoting from
>     [1]:
>     
>     When introducing a new advice message, you would
>     
>      * come up with advice.frotz configuration variable
>     
>      * define and declare advice_frotz global variable that defaults to
>        true
>     
>      * sprinkle calls like this:
>     
>       if (advice_frotz)
>         advise(_("helpful message about frotz"));
>     
>     A new approach was suggested in [1] which this patch is based upon.

I agree that the current procedure is a bit painful, and I think this is
a step in the right direction. But...

>     After this patch the plan is to migrate the rest of the advise calls to
>     advise_ng and then finally remove advise() and rename advise_ng() to
>     advise()

...this step may not be possible, for a few reasons:

  1. Some of the sites do more than just advise(). E.g., branch.c checks
     the flag and calls both error() and advise().

  2. Some callers may have to do work to generate the arguments. If I
     have:

       advise("advice.foo", "some data: %s", generate_data());

     then we'll call generate_data() even if we'll throw away the result
     in the end.

Similarly, some users of advice_* variables do not call advise() at all
(some call die(), some like builtin/rm.c stuff the result in a strbuf,
and I don't even know what's going on with wt_status.hints. :)

So I think you may need to phase it in a bit more, like:

  a. introduce want_advice() which decides whether or not to show the
     advice based on a config key. I'd also suggest making the "advice."
     part of the key implicit, just to make life easier for the callers.

  b. introduce advise_key() which uses want_advice() and advise() under
     the hood to do what your advise_ng() is doing here.

  c. convert simple patterns of:

       if (advice_foo)
          advise("bar");

     into:

       advise_key("foo", "bar");

     and drop advice_foo where possible.

  d. handle more complex cases one-by-one. For example, with something
     like:

       if (advice_foo)
         die("bar");

     we probably want:

       if (want_advice("foo"))
         die("bar");

     instead. Using string literals is more accident-prone than
     variables (because the compiler doesn't notice if we misspell them)
     but I think is OK for cases where we just refer to the key once.
     For others (e.g., advice_commit_before_merge has 13 mentions),
     either keep the variable. Or alternatively make a wrapper like:

       int want_advice_commit_before_merge(void)
       {
               return want_advice("commitbeforemerge");
       }

     if we want to drop the existing mechanism to load all of the
     variables at the beginning.

-Peff

[gitgitgadget]

On the Git mailing list, Emily Shaffer wrote (reply to this):

On Mon, Feb 10, 2020 at 11:42:53AM -0800, Taylor Blau wrote:
> On Mon, Feb 10, 2020 at 11:30:46AM -0800, Junio C Hamano wrote:
> > Derrick Stolee <[email protected]> writes:
> >
> > >> +static const char turn_off_instructions[] =
> > >> +N_("\n"
> > >> +"Turn this message off by running\n"
> > >> +"\"git config %s false\"");
> > >
> > > I have mixed feelings on the use of these instructions. Perhaps at
> > > minimum the addition of these instructions could be left to a
> > > separate patch than the creation of advise_ng().
> > >
> > > My biggest concern is that this adds unexpected noise to users who
> > > want the advice to stay. I'm calling attention to it, because this
> > > part isn't a simple refactor like the rest of the patch.
> > > ...
> > > I definitely tend to recommend more tests than most, but perhaps this
> > > unit test is overkill? You demonstrate a good test below using a real
> > > Git command, which should be sufficient. If the "turn this message off"
> > > part gets removed, then you will still have coverage of your method.
> > > It just won't require a test change because it would not modify behavior.
> > > ...
> >
> > All good suggestions.  Thanks for an excellent review.
> >
> > Another thing.
> >
> > advise_ng() may have been a good name for illustration but is a
> > horrible name for real-world use (imagine we need to revamp the API
> > one more time in the future---what would it be called, which has to
> > say that it is newer than the "next generation"?
> > advise_3rd_try()?).
> 
> What about calling this new API 'advise()'? The first patch could call
> it 'advise_ng' or whatever other temporary name we feel comfortable
> using, and then each subsequent patch would update callers of 'advise()'
> to use 'advise_ng()'. Once those patches have been applied, and no other
> callers of 'advise()' exist, a final patch can be applied on top to
> rename 'advise_ng()' to 'advise()', and update the names of all of the
> callers.

I think this is the precise strategy called out in the patch
description.
https://lore.kernel.org/git/[email protected]

> This makes for a rather noisy final patch, but the intermediate states
> are much clearer, and it would make this series rather self-contained.
> 
> On the other hand, having a version of 'advise_ng()' on master makes
> this topic more incremental, meaning that we can pick it up and put it
> down at ease and have more self-contained projects.
> 
> I don't really have a preference between the two approaches, but if we
> go with the latter, I do think we need something better than
> 'advise_ng'. Maybe 'advise_warn'? I don't know.

I like that this opens up the possibility of advise_err(), advise_die(),
whatever to meet Peff's suggestion.

 - Emily

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Heba Waly via GitGitGadget" <[email protected]> writes:

>     A new advise_ng() is introduced to gradually replace advise()
>     
>     pros of the new advise():
>     
>      * The caller doesn't need to define a new global variable when
>        introducing a new message.
>      * The caller doesn't need to check the visibility of the message before
>        calling advise_ng().
>      * The caller still needs to come up with advice.frotz config variable
>        and will call advice_ng as follows: advice_ng("advice.frotz",
>        _("helpful message about frotz"));

Readers would expect to see "cons of the same" to follow "pros".

>     After this patch the plan is to migrate the rest of the advise calls to
>     advise_ng and then finally remove advise() and rename advise_ng() to
>     advise()

As I outlined in [1], I think the over-simplified
"advise_ng(<advise.key>, _(<message>), ...)"  would be too limited
to replace the current users, without a pair of helper functions,
one to just check for the guarding advise.key, and the other to
unconditionally show the message (i.e. the latter is what the
current advise() is).

>     [1] 
>     https://public-inbox.org/git/[email protected]/

[gitgitgadget]

On the Git mailing list, Emily Shaffer wrote (reply to this):

On Mon, Feb 10, 2020 at 03:37:25PM -0500, Jeff King wrote:
> On Mon, Feb 10, 2020 at 05:04:09AM +0000, Heba Waly via GitGitGadget wrote:
> 
> >     The advice API is currently a little bit confusing to call. quoting from
> >     [1]:
> >     
> >     When introducing a new advice message, you would
> >     
> >      * come up with advice.frotz configuration variable
> >     
> >      * define and declare advice_frotz global variable that defaults to
> >        true
> >     
> >      * sprinkle calls like this:
> >     
> >       if (advice_frotz)
> >         advise(_("helpful message about frotz"));
> >     
> >     A new approach was suggested in [1] which this patch is based upon.
> 
> I agree that the current procedure is a bit painful, and I think this is
> a step in the right direction. But...
> 
> >     After this patch the plan is to migrate the rest of the advise calls to
> >     advise_ng and then finally remove advise() and rename advise_ng() to
> >     advise()
> 
> ...this step may not be possible, for a few reasons:
> 
>   1. Some of the sites do more than just advise(). E.g., branch.c checks
>      the flag and calls both error() and advise().
> 
>   2. Some callers may have to do work to generate the arguments. If I
>      have:
> 
>        advise("advice.foo", "some data: %s", generate_data());
> 
>      then we'll call generate_data() even if we'll throw away the result
>      in the end.
> 
> Similarly, some users of advice_* variables do not call advise() at all
> (some call die(), some like builtin/rm.c stuff the result in a strbuf,
> and I don't even know what's going on with wt_status.hints. :)
> 
> So I think you may need to phase it in a bit more, like:
> 
>   a. introduce want_advice() which decides whether or not to show the
>      advice based on a config key. I'd also suggest making the "advice."
>      part of the key implicit, just to make life easier for the callers.
> 
>   b. introduce advise_key() which uses want_advice() and advise() under
>      the hood to do what your advise_ng() is doing here.
> 
>   c. convert simple patterns of:
> 
>        if (advice_foo)
>           advise("bar");
> 
>      into:
> 
>        advise_key("foo", "bar");
> 
>      and drop advice_foo where possible.
> 
>   d. handle more complex cases one-by-one. For example, with something
>      like:
> 
>        if (advice_foo)
>          die("bar");
> 
>      we probably want:
> 
>        if (want_advice("foo"))
>          die("bar");
> 
>      instead. Using string literals is more accident-prone than
>      variables (because the compiler doesn't notice if we misspell them)
>      but I think is OK for cases where we just refer to the key once.
>      For others (e.g., advice_commit_before_merge has 13 mentions),
>      either keep the variable. Or alternatively make a wrapper like:
> 
>        int want_advice_commit_before_merge(void)
>        {
>                return want_advice("commitbeforemerge");
>        }
> 
>      if we want to drop the existing mechanism to load all of the
>      variables at the beginning.

I tend to disagree on both counts. I'd personally rather see something
like 'void advise_key(enum advice, char *format, ...)'.

As I understand it, Heba wanted to avoid that pattern so that people
adding a new advice didn't need to modify the advice library. However, I
think there's value to having a centralized list of all possible advices
(besides the documentation). The per-advice wrapper is harder to iterate
than an enum, and will also result in a lot of samey code if we decide
we want to use that pattern for more advices.

(In fact, with git-bugreport I'm running into a lot of regret that hooks
are invoked in the way Peff describes - 'find_hook("pre-commit")' -
rather than with an enum naming the hook; it's very hard to check all
possible hooks, and hard to examine the codebase and determine which
hooks do and don't exist.)

When Heba began to describe this project I had hoped for a final product
like 'void show_advice(enum advice_config)' which looked up the
appropriate string from the advice library instead of asking the caller
to provide it, although seeing the need for varargs has demonstrated to
me that that's not feasible :) But I think taking the advice config key
as an argument is possibly too far the other direction. At that point,
it starts to beg the question, "why isn't this function in config.h and
called print_if_configured(cfgname, message, ...)?"

Although, take this all with a grain of salt. I think I lean towards
this much encapsulation after a sordid history with C++ and an
enlightened C developer may not choose it ;)

 - Emily

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Tue, Feb 11, 2020 at 3:38 AM Derrick Stolee <[email protected]> wrote:
>
> On 2/10/2020 12:04 AM, Heba Waly via GitGitGadget wrote:
> > From: Heba Waly <[email protected]>
> >
> > Add a new advise_ng function that can check the visibility of advice
> > messages before printing.
> >
> > Currently it's very easy for the callers to miss checking the
> > visibility step. Also, it makes more sense for this step to be handled
> > by the advice library.
>
> This makes the advice API much easier and its uses much cleaner. Thanks!
>
> > Also change the advise call in tag library from advise() to advise_ng()
> > to construct an example of the usage of the new API.
>
> This is a good example case.
>
> > +static const char turn_off_instructions[] =
> > +N_("\n"
> > +"Turn this message off by running\n"
> > +"\"git config %s false\"");
>
> I have mixed feelings on the use of these instructions. Perhaps at
> minimum the addition of these instructions could be left to a
> separate patch than the creation of advise_ng().
>
> My biggest concern is that this adds unexpected noise to users who
> want the advice to stay. I'm calling attention to it, because this
> part isn't a simple refactor like the rest of the patch.
>
> If it _does_ stay, then I recommend condensing the message to
> a single line. For example:
>
>         Disable this message with "git config %d false"
>

I agree with you, I had mixed feelings about it too when suggested on
a previous patch [2].
But then I realized that it's hard for the user to find the right
config variable to turn off from the doc only.
So I like the compromise of condensing it to a single line.

> > +     if(value)
> > +     {
>
> Style: spacing, and opening braces are on the same line as the if:
>
>         if (value) {
>
> But also, this method would be simpler if the opposite case was
> an early return:
>
>         if (!value)
>                 return;
> Then the rest could have one less indentation.

Agree

> This loop looks like it was copied from advise(). Perhaps we could
> re-use that code better by creating a new vadvise() method that
> takes a va_list, and have advise() and advise_ng() call it instead?
> I include a patch at the end of this method that does this conversion.
> (Feel free to incorporate it into your next version, if you want, but
> be sure to add your sign-off.) Then, your advise_ng() can call these:
>
>         vadvise(advice, params);
>         advise(turn_off_instructions, key);
>
> removing the need to re-implement the for loop.

My intention was to replace advise() by advise_ng(), so I didn't mind
a temp code repetition during the transition phase.
But as it seems like some folks would rather keep both, then yes of
course a vadvise() function is the way to go, thanks.

> > diff --git a/t/helper/test-advise.c b/t/helper/test-advise.c
> > new file mode 100644
> > index 0000000000..b6ec90fd18
> > --- /dev/null
> > +++ b/t/helper/test-advise.c
> > @@ -0,0 +1,15 @@
> > +#include "test-tool.h"
> > +#include "cache.h"
> > +#include "advice.h"
> > +
> > +int cmd__advise_ng(int argc, const char **argv)
> > +{
> > +     if (!argv[1] || !argv[2])
> > +     die("usage: %s <key> <advice>", argv[0]);
> > +
> > +     setup_git_directory();
> > +
> > +     advise_ng(argv[1], argv[2]);
> > +
> > +     return 0;
> > +}
>
> I definitely tend to recommend more tests than most, but perhaps this
> unit test is overkill? You demonstrate a good test below using a real
> Git command, which should be sufficient. If the "turn this message off"
> part gets removed, then you will still have coverage of your method.
> It just won't require a test change because it would not modify behavior.
>

I see your point but I wanted to make sure advise_ng honors the config
variable using tests 2 & 3 in `t0018-advice.sh`
and `t7004-tag.sh` didn't seem like a good place to add these tests.

> > diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> > index 6db92bd3ba..b7c8d41899 100755
> > --- a/t/t7004-tag.sh
> > +++ b/t/t7004-tag.sh
> > @@ -1726,6 +1726,8 @@ test_expect_success 'recursive tagging should give advice' '
> >       hint: already a tag. If you meant to tag the object that it points to, use:
> >       hint: |
> >       hint:   git tag -f nested annotated-v4.0^{}
> > +     hint: Turn this message off by running
> > +     hint: "git config advice.nestedTag false"
> >       EOF
> >       git tag -m nested nested annotated-v4.0 2>actual &&
> >       test_i18ncmp expect actual
> >
> > base-commit: c7a62075917b3340f908093f63f1161c44ed1475
>
> Thanks,
> -Stolee
>
> -->8--
>
> From: Derrick Stolee <[email protected]>
> Date: Mon, 10 Feb 2020 09:33:20 -0500
> Subject: [PATCH] advice: extract vadvise() from advise()
>
> In preparation for a new advice method, extract a version of advise()
> that uses an explict 'va_list' parameter. Call it from advise() for a
> functionally equivalent version.
>
> Signed-off-by: Derrick Stolee <[email protected]>
> ---
>  advice.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/advice.c b/advice.c
> index 249c60dcf3..fd836332da 100644
> --- a/advice.c
> +++ b/advice.c
> @@ -96,15 +96,12 @@ static struct {
>         { "pushNonFastForward", &advice_push_update_rejected }
>  };
>
> -void advise(const char *advice, ...)
> +static void vadvise(const char *advice, va_list params)
>  {
>         struct strbuf buf = STRBUF_INIT;
> -       va_list params;
>         const char *cp, *np;
>
> -       va_start(params, advice);
>         strbuf_vaddf(&buf, advice, params);
> -       va_end(params);
>
>         for (cp = buf.buf; *cp; cp = np) {
>                 np = strchrnul(cp, '\n');
> @@ -118,6 +115,14 @@ void advise(const char *advice, ...)
>         strbuf_release(&buf);
>  }
>
> +void advise(const char *advice, ...)
> +{
> +       va_list params;
> +       va_start(params, advice);
> +       vadvise(advice, params);
> +       va_end(params);
> +}
> +
>  int git_default_advice_config(const char *var, const char *value)
>  {
>         const char *k, *slot_name;
> --
> 2.25.0.vfs.1.1.1.g9906319d24.dirty
>
>
>

[2] https://lore.kernel.org/git/CACg5j26DEXuxwqRYHi5UOBUpRwsu_2A9LwgyKq4qB9wxqasD7g@mail.gmail.com/

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Tue, Feb 11, 2020 at 8:42 AM Taylor Blau <[email protected]> wrote:
>
> On Mon, Feb 10, 2020 at 11:30:46AM -0800, Junio C Hamano wrote:
> > Another thing.
> >
> > advise_ng() may have been a good name for illustration but is a
> > horrible name for real-world use (imagine we need to revamp the API
> > one more time in the future---what would it be called, which has to
> > say that it is newer than the "next generation"?
> > advise_3rd_try()?).

As I mentioned earlier, this patch is meant to be used as a transition
between the current advise() and the refactored one.
So the name is just temporary and it'll be renamed to advise() once
the transition is done.
But if we want to keep both functions, or want a better name because
it's an open-source project and the author might not complete the
transition, then I'll try to think of another name.

> What about calling this new API 'advise()'? The first patch could call
> it 'advise_ng' or whatever other temporary name we feel comfortable
> using, and then each subsequent patch would update callers of 'advise()'
> to use 'advise_ng()'. Once those patches have been applied, and no other
> callers of 'advise()' exist, a final patch can be applied on top to
> rename 'advise_ng()' to 'advise()', and update the names of all of the
> callers.
>

Yes, that's what I would like to do.

> This makes for a rather noisy final patch, but the intermediate states
> are much clearer, and it would make this series rather self-contained.
>
> On the other hand, having a version of 'advise_ng()' on master makes
> this topic more incremental, meaning that we can pick it up and put it
> down at ease and have more self-contained projects.
>
> I don't really have a preference between the two approaches, but if we
> go with the latter, I do think we need something better than
> 'advise_ng'. Maybe 'advise_warn'? I don't know.
>
> > Thanks.
>
> Thanks,
> Taylor

Thanks,
Heba

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Tue, Feb 11, 2020 at 11:46 AM Junio C Hamano <[email protected]> wrote:
>
>
> As I outlined in [1], I think the over-simplified
> "advise_ng(<advise.key>, _(<message>), ...)"  would be too limited
> to replace the current users, without a pair of helper functions,
> one to just check for the guarding advise.key, and the other to
> unconditionally show the message (i.e. the latter is what the
> current advise() is).
>

I agree with adding the first helper, specially after Peff's comments,
but I don't see why we would keep the current advise() which
unconditionally shows the message...
As far as I understand from a previous discussion [3], that's a wrong
usage that we need to avoid, quoting from [3]:
```
If there are many other places that calls to advise() are made
without getting guarded by the toggles defined in advice.c, we
should fix them, I think.
```

> >     [1]
> >     https://public-inbox.org/git/[email protected]/
[3] https://public-inbox.org/git/[email protected]/

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Tue, Feb 11, 2020 at 9:37 AM Jeff King <[email protected]> wrote:
>
> On Mon, Feb 10, 2020 at 05:04:09AM +0000, Heba Waly via GitGitGadget wrote:
>
> >     The advice API is currently a little bit confusing to call. quoting from
> >     [1]:
> >
> >     When introducing a new advice message, you would
> >
> >      * come up with advice.frotz configuration variable
> >
> >      * define and declare advice_frotz global variable that defaults to
> >        true
> >
> >      * sprinkle calls like this:
> >
> >       if (advice_frotz)
> >         advise(_("helpful message about frotz"));
> >
> >     A new approach was suggested in [1] which this patch is based upon.
>
> I agree that the current procedure is a bit painful, and I think this is
> a step in the right direction. But...
>
> >     After this patch the plan is to migrate the rest of the advise calls to
> >     advise_ng and then finally remove advise() and rename advise_ng() to
> >     advise()
>
> ...this step may not be possible, for a few reasons:
>
>   1. Some of the sites do more than just advise(). E.g., branch.c checks
>      the flag and calls both error() and advise().
>
>   2. Some callers may have to do work to generate the arguments. If I
>      have:
>
>        advise("advice.foo", "some data: %s", generate_data());
>
>      then we'll call generate_data() even if we'll throw away the result
>      in the end.
>
> Similarly, some users of advice_* variables do not call advise() at all
> (some call die(), some like builtin/rm.c stuff the result in a strbuf,
> and I don't even know what's going on with wt_status.hints. :)
>
> So I think you may need to phase it in a bit more, like:
>
>   a. introduce want_advice() which decides whether or not to show the
>      advice based on a config key. I'd also suggest making the "advice."
>      part of the key implicit, just to make life easier for the callers.
>

yes, I agree.

>   b. introduce advise_key() which uses want_advice() and advise() under
>      the hood to do what your advise_ng() is doing here.
>
>   c. convert simple patterns of:
>
>        if (advice_foo)
>           advise("bar");
>
>      into:
>
>        advise_key("foo", "bar");
>
>      and drop advice_foo where possible.
>
>   d. handle more complex cases one-by-one. For example, with something
>      like:
>
>        if (advice_foo)
>          die("bar");
>
>      we probably want:
>
>        if (want_advice("foo"))
>          die("bar");
>
>      instead. Using string literals is more accident-prone than
>      variables (because the compiler doesn't notice if we misspell them)
>      but I think is OK for cases where we just refer to the key once.
>      For others (e.g., advice_commit_before_merge has 13 mentions),
>      either keep the variable. Or alternatively make a wrapper like:
>
>        int want_advice_commit_before_merge(void)
>        {
>                return want_advice("commitbeforemerge");
>        }
>
>      if we want to drop the existing mechanism to load all of the
>      variables at the beginning.
>

All make sense to me, thanks for the feedback.

> -Peff

Heba

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Tue, Feb 11, 2020 at 11:55 AM Emily Shaffer <[email protected]> wrote:
>
> On Mon, Feb 10, 2020 at 03:37:25PM -0500, Jeff King wrote:
> >
> >      instead. Using string literals is more accident-prone than
> >      variables (because the compiler doesn't notice if we misspell them)
> >      but I think is OK for cases where we just refer to the key once.
> >      For others (e.g., advice_commit_before_merge has 13 mentions),
> >      either keep the variable. Or alternatively make a wrapper like:
> >
> >        int want_advice_commit_before_merge(void)
> >        {
> >                return want_advice("commitbeforemerge");
> >        }
> >
> >      if we want to drop the existing mechanism to load all of the
> >      variables at the beginning.
>
> I tend to disagree on both counts. I'd personally rather see something
> like 'void advise_key(enum advice, char *format, ...)'.
>
> As I understand it, Heba wanted to avoid that pattern so that people
> adding a new advice didn't need to modify the advice library. However, I
> think there's value to having a centralized list of all possible advices
> (besides the documentation). The per-advice wrapper is harder to iterate
> than an enum, and will also result in a lot of samey code if we decide
> we want to use that pattern for more advices.
>

I think Peff is suggesting the wrapper for only those rare cases where
a single advice config variable is being checked several times around
the code base, but this doesn't mean we'll have many of them. In my
own opinion, I don't see the need for the list of advices, I think
it'll add unneeded complexity to the advice library and the
introduction of new advice messages. Mainly because I don't see a
scenario where we'd need to iterate through them, so I don't know ...

> (In fact, with git-bugreport I'm running into a lot of regret that hooks
> are invoked in the way Peff describes - 'find_hook("pre-commit")' -
> rather than with an enum naming the hook; it's very hard to check all
> possible hooks, and hard to examine the codebase and determine which
> hooks do and don't exist.)
>
> When Heba began to describe this project I had hoped for a final product
> like 'void show_advice(enum advice_config)' which looked up the
> appropriate string from the advice library instead of asking the caller
> to provide it, although seeing the need for varargs has demonstrated to
> me that that's not feasible :) But I think taking the advice config key
> as an argument is possibly too far the other direction. At that point,
> it starts to beg the question, "why isn't this function in config.h and
> called print_if_configured(cfgname, message, ...)?"
>
> Although, take this all with a grain of salt. I think I lean towards
> this much encapsulation after a sordid history with C++ and an
> enlightened C developer may not choose it ;)
>
>  - Emily

[gitgitgadget]

On the Git mailing list, Derrick Stolee wrote (reply to this):

On 2/10/2020 6:56 PM, Heba Waly wrote:
> On Tue, Feb 11, 2020 at 3:38 AM Derrick Stolee <[email protected]> wrote:
>>
>> I definitely tend to recommend more tests than most, but perhaps this
>> unit test is overkill? You demonstrate a good test below using a real
>> Git command, which should be sufficient. If the "turn this message off"
>> part gets removed, then you will still have coverage of your method.
>> It just won't require a test change because it would not modify behavior.
>>
> 
> I see your point but I wanted to make sure advise_ng honors the config
> variable using tests 2 & 3 in `t0018-advice.sh`
> and `t7004-tag.sh` didn't seem like a good place to add these tests.

You're right. I wasn't considering the case of not showing the message
with respect to the config.

-Stolee

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

Heba Waly <[email protected]> writes:

> On Tue, Feb 11, 2020 at 11:46 AM Junio C Hamano <[email protected]> wrote:
>>
>>
>> As I outlined in [1], I think the over-simplified
>> "advise_ng(<advise.key>, _(<message>), ...)"  would be too limited
>> to replace the current users, without a pair of helper functions,
>> one to just check for the guarding advise.key, and the other to
>> unconditionally show the message (i.e. the latter is what the
>> current advise() is).
>>
>
> I agree with adding the first helper, specially after Peff's comments,
> but I don't see why we would keep the current advise() which
> unconditionally shows the message...

Look again at the message you referenced in your message that
started this round, and read its comment:

	if (advise_ng_enabled("frotz")) {
		char *result = expensive_computation(...);

		/*
                 * advise_ng("frotz", _("message %s about frotz", result));
                 * is fine as well, but slightly less efficient as
                 * it would involve another call to *_enabled(), so use
		 * the unconditional form of the call
		 */
		advise_ng_raw(_("message %s about frotz", result));

		free(result);
	}

[gitgitgadget]

On the Git mailing list, Jeff King wrote (reply to this):

On Mon, Feb 10, 2020 at 02:55:28PM -0800, Emily Shaffer wrote:

> I tend to disagree on both counts. I'd personally rather see something
> like 'void advise_key(enum advice, char *format, ...)'.

Yeah, I don't mind that at all. It's mutually exclusive with not making
people add new enums when they want to add new advice types, but as you
note we do get some code maintenance benefit by having the variables,
even if _adding_ a new one is a slightly larger pain.

-Peff

[gitgitgadget]

On the Git mailing list, Jeff King wrote (reply to this):

On Tue, Feb 11, 2020 at 02:49:43PM -0500, Jeff King wrote:

> On Mon, Feb 10, 2020 at 02:55:28PM -0800, Emily Shaffer wrote:
> 
> > I tend to disagree on both counts. I'd personally rather see something
> > like 'void advise_key(enum advice, char *format, ...)'.
> 
> Yeah, I don't mind that at all. It's mutually exclusive with not making
> people add new enums when they want to add new advice types, but as you
> note we do get some code maintenance benefit by having the variables,
> even if _adding_ a new one is a slightly larger pain.

Thinking on it a bit more, one argument in favor of having enums or
variables or whatever is that we _do_ need a master list of all of the
variables in one spot: the documentation.

So one direction we _could_ go is either generating the enum from the
documentation or vice versa (or generating both from a master list).
That would give us one place to define a new key along with its
description.

-Peff

[gitgitgadget]

On the Git mailing list, Taylor Blau wrote (reply to this):

On Tue, Feb 11, 2020 at 01:08:48PM +1300, Heba Waly wrote:
> On Tue, Feb 11, 2020 at 8:42 AM Taylor Blau <[email protected]> wrote:
> >
> > On Mon, Feb 10, 2020 at 11:30:46AM -0800, Junio C Hamano wrote:
> > > Another thing.
> > >
> > > advise_ng() may have been a good name for illustration but is a
> > > horrible name for real-world use (imagine we need to revamp the API
> > > one more time in the future---what would it be called, which has to
> > > say that it is newer than the "next generation"?
> > > advise_3rd_try()?).
>
> As I mentioned earlier, this patch is meant to be used as a transition
> between the current advise() and the refactored one.

Ah, thanks for pointing it out, and I'm sorry that I missed reading it
in my first review. Your idea sounds quite good to me, and thanks for
working on this.

> So the name is just temporary and it'll be renamed to advise() once
> the transition is done.
> But if we want to keep both functions, or want a better name because
> it's an open-source project and the author might not complete the
> transition, then I'll try to think of another name.
>
> > What about calling this new API 'advise()'? The first patch could call
> > it 'advise_ng' or whatever other temporary name we feel comfortable
> > using, and then each subsequent patch would update callers of 'advise()'
> > to use 'advise_ng()'. Once those patches have been applied, and no other
> > callers of 'advise()' exist, a final patch can be applied on top to
> > rename 'advise_ng()' to 'advise()', and update the names of all of the
> > callers.
> >
>
> Yes, that's what I would like to do.
>
> > This makes for a rather noisy final patch, but the intermediate states
> > are much clearer, and it would make this series rather self-contained.
> >
> > On the other hand, having a version of 'advise_ng()' on master makes
> > this topic more incremental, meaning that we can pick it up and put it
> > down at ease and have more self-contained projects.
> >
> > I don't really have a preference between the two approaches, but if we
> > go with the latter, I do think we need something better than
> > 'advise_ng'. Maybe 'advise_warn'? I don't know.
> >
> > > Thanks.
> >
> > Thanks,
> > Taylor
>
> Thanks,
> Heba

Thanks,
Taylor

[HebaWaly]

/submit

[gitgitgadget]

Submitted as [email protected]

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Heba Waly via GitGitGadget" <[email protected]> writes:

> Main changes in V2: 1- Rename advise_ng to advise_if_enabled. 2- Add a new
> advise_enabled() helper. 3- Add a list of config variables names to replace
> advice_config[] (used by list_config_advices()). 4- Send an enum parameter
> to the new advise helpers instead of strings. 5- Extract vadvise() from
> advise() and advise_if enabled().


Nice.  There is not much point for me to correct mistakes in the
title of the cover letter, but anyway... I think these changes are
not "refactoring" the API, but these are enhancing, extending or
even revamping the API.  

> To introduce a new advice message, the caller needs to:
>
>  * Add a new_advice_type to 'enum advice_type'
>  * Come up with a new config variable name and add this name to 
>    advice_config_keys[]
>  * Call advise_if_enabled(new_advice_type, "advice message to be printed")
>  * Or call advice_enabled(new_advice_type) first and then follow is by
>    advice("advice message to be printed") as explained earlier.
>  * Add the new config variable to Documentation/config/advice.txt

And I see that now you are going all the way to discard the
string-based keys to enumeration, I think this deserves to be called
"revamp advise API".

> In the future, we can investigate generating the documentation from the list
> of config variables or vice versa to make introducing a new advice much
> easier, but this approach will do it for now.

Yup.  One step at a time.

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

There seem to be a handful of lines with trailing whitespaces.  I
think I've fixed them all on the receiving end, but please proofread
before you come up with the next round.

Thanks.

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Mon, Feb 17, 2020 at 4:28 PM Junio C Hamano <[email protected]> wrote:
>
>And I see that now you are going all the way to discard the
>string-based keys to enumeration, I think this deserves to be called
>"revamp advise API".

Fair enough.

> There seem to be a handful of lines with trailing whitespaces.  I
> think I've fixed them all on the receiving end, but please proofread
> before you come up with the next round.
>

Sorry about that, I fixed this setting in my IDE a while ago but looks
like it has a bug.
Will keep an eye on it in the future, thanks

> Thanks.

Heba

[gitgitgadget]

This branch is now known as hw/advise-ng.

[gitgitgadget]

Submitted as [email protected]

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Heba Waly via GitGitGadget" <[email protected]> writes:

> +static struct {
> +	const char *key;
> +	int enabled;
> +} advice_setting[] = {
> +	[ADVICE_ADD_EMBEDDED_REPO]			= { "addEmbeddedRepo", 1 },

It would be nicer to future developers to flip the polarity, as we
do not have to write 1 all over the place, especially if we plan to
extend the structure over time and to use designated initializers
for only certain fields:

	static struct {
		const char *key;
		int disabled;
	} advice_setting[] = {
		[ADDVICE_ADD_EMBEDDED_REPO] = { .key = "addEmbeddedRepo" },

> @@ -149,6 +218,13 @@ int git_default_advice_config(const char *var, const char *value)
>  		if (strcasecmp(k, advice_config[i].name))
>  			continue;
>  		*advice_config[i].preference = git_config_bool(var, value);
> +		break;
> +	}
> +
> +	for (i = 0; i < ARRAY_SIZE(advice_setting); i++) {
> +		if (strcasecmp(k, advice_setting[i].key))
> +			continue;
> +		advice_setting[i].enabled = git_config_bool(var, value);
>  		return 0;

Turning this into "break;" would make it similar to the loop before
this one, and will allow other people to add more code after this
loop later.

> +int cmd__advise_if_enabled(int argc, const char **argv)
> +{
> +	if (!argv[1])
> +	die("usage: %s <advice>", argv[0]);
> +
> +	setup_git_directory();
> +	git_config(git_default_config, NULL);
> +
> +	/*
> +	  Any advice type can be used for testing, but NESTED_TAG was selected
> +	  here and in t0018 where this command is being executed.
> +	 */

Style (will fix up locally).

Thanks.  I think this is reasonable with or without the suggested
fixes.

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

Junio C Hamano <[email protected]> writes:

> "Heba Waly via GitGitGadget" <[email protected]> writes:
>
>> +static struct {
>> +	const char *key;
>> +	int enabled;
>> +} advice_setting[] = {
>> +	[ADVICE_ADD_EMBEDDED_REPO]			= { "addEmbeddedRepo", 1 },
>
> It would be nicer to future developers to flip the polarity, as we
> do not have to write 1 all over the place, especially if we plan to
> extend the structure over time and to use designated initializers
> for only certain fields...

Just to avoid needless churn, I think this does not matter in the
longer term, so .enabled is OK as-is.  The reason I say so is
because, even though renaming to .disabled to allow initializers to
default it to 0 is nicer for those who write the initializers
manually, and it especially is true when we have more fields in the
struct (we may add descriptive text so that we can issue an on-line
help, for example), but I expect that would happen much later than
we start generating these parts of the source code in two places
(the initializer for advice_setting[] and the advice_type enum) from
a single source by mechanical process.  And the auto-generation will
eliminate the burden of writing 1 manually.

[gitgitgadget]

On the Git mailing list, Heba Waly wrote (reply to this):

On Wed, Mar 4, 2020 at 3:16 AM Junio C Hamano <[email protected]> wrote:
>
> Junio C Hamano <[email protected]> writes:
>
> > "Heba Waly via GitGitGadget" <[email protected]> writes:
> >
> >> +static struct {
> >> +    const char *key;
> >> +    int enabled;
> >> +} advice_setting[] = {
> >> +    [ADVICE_ADD_EMBEDDED_REPO]                      = { "addEmbeddedRepo", 1 },
> >
> > It would be nicer to future developers to flip the polarity, as we
> > do not have to write 1 all over the place, especially if we plan to
> > extend the structure over time and to use designated initializers
> > for only certain fields...
>
> Just to avoid needless churn, I think this does not matter in the
> longer term, so .enabled is OK as-is.  The reason I say so is
> because, even though renaming to .disabled to allow initializers to
> default it to 0 is nicer for those who write the initializers
> manually, and it especially is true when we have more fields in the
> struct (we may add descriptive text so that we can issue an on-line
> help, for example), but I expect that would happen much later than
> we start generating these parts of the source code in two places
> (the initializer for advice_setting[] and the advice_type enum) from
> a single source by mechanical process.  And the auto-generation will
> eliminate the burden of writing 1 manually.

Agree.

> Turning this into "break;" would make it similar to the loop before
> this one, and will allow other people to add more code after this
> loop later.

The loop with break is redundant and will be removed in the next
patch, but the rest of the loops in this function end with return
which I think makes more sense assuming any new code/loop that will
need to be added in the future is expected to handle a different
configuration group.

> > +     /*
> > +       Any advice type can be used for testing, but NESTED_TAG was selected
> > +       here and in t0018 where this command is being executed.
> > +      */
>
> Style (will fix up locally).
>
> Thanks.  I think this is reasonable with or without the suggested
> fixes.

Great, thanks.

Heba

[gitgitgadget]

This patch series was integrated into pu via git@20bc48f.

[gitgitgadget]

This patch series was integrated into pu via git@f084d93.

[gitgitgadget]

This patch series was integrated into pu via git@0ae1e05.

[gitgitgadget]

This patch series was integrated into pu via git@b90e6e8.

[gitgitgadget]

This patch series was integrated into pu via git@45f98be.

[gitgitgadget]

This patch series was integrated into pu via git@eb833f4.

[gitgitgadget]

This patch series was integrated into next via git@ea9e5a1.

[gitgitgadget]

This patch series was integrated into pu via git@6159684.

[gitgitgadget]

This patch series was integrated into pu via git@c332b88.

[gitgitgadget]

This patch series was integrated into pu via git@1e6d758.

[gitgitgadget]

This patch series was integrated into pu via git@0bd68b2.

[gitgitgadget]

This patch series was integrated into pu via git@f30f916.

[gitgitgadget]

This patch series was integrated into pu via git@ef65f35.

[gitgitgadget]

This patch series was integrated into pu via git@51b547d.

[gitgitgadget]

This patch series was integrated into pu via git@b65dd7e.

[gitgitgadget]

This patch series was integrated into pu via git@0d75da2.

[gitgitgadget]

This patch series was integrated into pu via git@820bc22.

[gitgitgadget]

This patch series was integrated into pu via git@951f464.

[gitgitgadget]

This patch series was integrated into pu via git@7297bb2.

[gitgitgadget]

This patch series was integrated into pu via git@d625c35.

[gitgitgadget]

This patch series was integrated into pu via git@953f4ff.

[gitgitgadget]

This patch series was integrated into pu via git@c4a09cc.

[gitgitgadget]

This patch series was integrated into next via git@c4a09cc.

[gitgitgadget]

This patch series was integrated into master via git@c4a09cc.

[gitgitgadget]

Closed via c4a09cc.