Re: [PATCH] builtin/send-pack: populate the default configs

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jun 12, 2018, 18:22 UTC
Message-ID: <CAPig+cQZe2TH01eWOYE2Gzo9vTjMoEAQFxZZhu7vcE2jwV9Yuw@mail.gmail.com>
In-Reply-To: <20180612181624.GB28554@aiede.svl.corp.google.com>

On Tue, Jun 12, 2018 at 2:16 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 26 quoted lines

> Masaya Suzuki wrote:
>> builtin/send-pack didn't call git_default_config, and because of this
>> git push --signed didn't respect the username and email in gitconfig in
>> the HTTP transport.
>>
>> Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
>> ---
> send-pack is not a command served by a daemon so this is less
> potentially scary than the corresponding potential change to
> upload-pack or receive-pack.  Some configuration this brings in:
>
> - core.askpass: allows specifying an arbitrary command to use to
>   ask for a password.  Respecting this setting should be very useful,
>   even if it would be scary in a daemon.
>
> - core.pager: allows specifying an arbitrary command to use as a
>   pager, if pagination is on (but it shouldn't be on).
> - core.logallrefupdates: whether to create reflogs for new refs
>   (including new remote-tracking refs). Good.
> - core.abbrev: what length of abbreviations to use when printing
>   abbreviated object ids (good).
> - core.compression, core.packedgitwindowsize, etc: pack generation
>   tunables (good).
> - advice.*: would allow us to make "git push" produce configurable
>   advice (good!)
> - etc

This summary probably ought to be in the commit message itself (plus additional commentary implied by the ending "etc."). It's exactly the sort of information someone looking at this patch in the future will want to know to feel assured that such behavior changes were taken into account by the patch author.