Re: [PATCH v2 2/2] format-patch: teach format.notes config option
- From
Beat Bolli <dev+git@drbeat.li>
- Date
- May 8, 2019, 17:52 UTC
- Message-ID
- <d5dc0655-9753-6343-2235-6cbd1bd2e198@drbeat.li>
- In-Reply-To
- <20190508173122.GA23712@archbookpro.localdomain>
On 08.05.19 19:31, Denton Liu wrote:
Show 102 quoted lines
> Hi Beat,
>
> On Wed, May 08, 2019 at 07:18:18PM +0200, Beat Bolli wrote:
>> On 08.05.19 17:02, Denton Liu wrote:
>>> In git-format-patch, notes can be appended with the `--notes` option.
>>> However, this must be specified by the user on an
>>> invocation-by-invocation basis. If a user is not careful, it's possible
>>> that they may forget to include it and generate a patch series without
>>> notes.
>>>
>>> Teach git-format-patch the `format.notes` config option its value is a
>>
>> s/its/. Its/
>>
>>> notes ref that will be automatically be appended. The special value of
>>
>> Drop the second "be ".
>
> Thanks, I should've read through the log message more carefully before
> sending.
>
>>
>>> "standard" can be used to specify the standard notes. This option is
>>> overridable with the `--no-notes` option in case a user wishes not to
>>> append notes.
>>>
>>> Signed-off-by: Denton Liu <liu.denton@gmail.com>
>>> ---
>>> One thing I'm worried about is that I'm not really sure using "standard"
>>> as the special value is a good idea. Would "auto" be a better special
>>> value?
>>>
>>> Documentation/config/format.txt | 13 ++++++
>>> Documentation/git-format-patch.txt | 3 ++
>>> builtin/log.c | 18 +++++++-
>>> t/t4014-format-patch.sh | 70 ++++++++++++++++++++++++++++++
>>> 4 files changed, 103 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/config/format.txt b/Documentation/config/format.txt
>>> index dc77941c48..e25f9cfc61 100644
>>> --- a/Documentation/config/format.txt
>>> +++ b/Documentation/config/format.txt
>>> @@ -85,3 +85,16 @@ format.outputDirectory::
>>> format.useAutoBase::
>>> A boolean value which lets you enable the `--base=auto` option of
>>> format-patch by default.
>>> +
>>> +format.notes::
>>> + A ref which specifies where to get the notes (see
>>> + linkgit:git-notes[1]) that are appended for the commit after the
>>> + three-dash line.
>>> ++
>>> +If the special value of "standard" is specified, then the standard notes
>>> +ref is used (i.e. the notes ref used by `git notes` when no `--ref`
>>> +argument is specified). If one wishes to use the ref
>>> +`ref/notes/standard`, please use that literal instead.
>>> ++
>>> +This configuration can be specified multiple times in order to allow
>>> +multiple notes refs to be included.
>>> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
>>> index 2c3971390e..9ce5b8aaee 100644
>>> --- a/Documentation/git-format-patch.txt
>>> +++ b/Documentation/git-format-patch.txt
>>> @@ -275,6 +275,9 @@ these explanations after `format-patch` has run but before sending,
>>> keeping them as Git notes allows them to be maintained between versions
>>> of the patch series (but see the discussion of the `notes.rewrite`
>>> configuration options in linkgit:git-notes[1] to use this workflow).
>>> ++
>>> +The default is `--no-notes`, unless the `format.notes` configuration is
>>> +set.
>>>
>>> --[no-]signature=<signature>::
>>> Add a signature to each message produced. Per RFC 3676 the signature
>>> diff --git a/builtin/log.c b/builtin/log.c
>>> index e43ee12fb1..24954e42b0 100644
>>> --- a/builtin/log.c
>>> +++ b/builtin/log.c
>>> @@ -779,6 +779,8 @@ enum {
>>>
>>> static int git_format_config(const char *var, const char *value, void *cb)
>>> {
>>> + struct rev_info *rev = cb;
>>> +
>>> if (!strcmp(var, "format.headers")) {
>>> if (!value)
>>> die(_("format.headers without value"));
>>> @@ -864,6 +866,20 @@ static int git_format_config(const char *var, const char *value, void *cb)
>>> from = NULL;
>>> return 0;
>>> }
>>> + if (!strcmp(var, "format.notes")) {
>>> + struct strbuf buf = STRBUF_INIT;
>>> +
>>> + rev->show_notes = 1;
>>> + if (!strcmp(value, "standard"))
>>> + rev->notes_opt.use_default_notes = 1;
>>> + else {
>>
>> Use braces on both parts of the "if", if one part needs them.
>
> I thought that the style preference in this project is to not use braces
> whenever it's unnecessary, even if it's on just one arm of an if-else.No, Documentation/CodingGuidelines mentions this case explicitly. Search for "multiple arms".
ATB, Beat