[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v5 09/15] bugreport: generate config safelist based on docs
From:       Martin_Ågren <martin.agren () gmail ! com>
Date:       2020-01-31 21:20:05
Message-ID: CAN0heSo2ujJr_Mi5xPv86NneLoXT3DM3dnRmTACs2VQERBq76Q () mail ! gmail ! com
[Download RAW message or body]

On Fri, 24 Jan 2020 at 04:35, <emilyshaffer@google.com> wrote:
> Add a new step to the build to generate a safelist of git-config
> variables which are appropriate to include in the output of
> git-bugreport. New variables can be added to the safelist by annotating
> their documentation in Documentation/config with the
> "bugreport" macro, which is recognized by AsciiDoc and
> AsciiDoctor.

"which is recognized by" sounds like it's built-in. Maybe "with a new
no-op 'bugreport' macro" or something like that.

> -sendemail.signedoffcc (deprecated)::
> +sendemail.signedoffcc (deprecated) bugreport:exclude[x] ::
>         Deprecated alias for `sendemail.signedoffbycc`.
>
> -sendemail.smtpBatchSize::
> +sendemail.smtpBatchSize bugreport:include[x] ::
>         Number of messages to be sent per connection, after that a relogin
>         will happen.  If the value is 0 or undefined, send all messages in
>         one connection.
>         See also the `--batch-size` option of linkgit:git-send-email[1].

Do we really need to list includes *and* excludes? I could see the point
of adding an exclude here and there to signal that "this might look
innocent enough, but trust me, we really need to exclude this" in order
to avoid future commits to more or less accidentally over-include.
Should we add some internal documentation and/or a remark in the commit
message about this? As an example, is "sendemail.signedofcc" sensitive
enough that we need to explicitly exclude it? If someone wants to come
along and include it, they don't just need to argue for an inclusion,
but also for lifting the exclusion. Hmm?

Martin
[prev in list] [next in list] [prev in thread] [next in thread]