Re: [PATCH v2 1/9] cherry-pick, revert: add the --gpg-sign option

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2014, 22:45 UTC
Message-ID: <xmqqa9elq9re.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140124210836.GA58260@vauxhall.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 15 quoted lines

> On Fri, Jan 24, 2014 at 01:00:06PM -0800, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>> 
>> > +-S[<keyid>]::
>> > +--gpg-sign[=<keyid>]::
>> > +	GPG-sign commits.
>> > +
>> 
>> Does this accept --no-gpg-sign?  If not, shouldn't it?
>
> It does not.  I took Nicolas's patches from the list and applied them to
> master, so nothing from next is there, including the commit.gpgsign
> stuff.
>
> Would you prefer I rebased them on next instead?

Not really.

It is debatable if it should mean that the user wants to sign commits that are created by running other commands like "am" and "stash" when he sets commit.gpgsign to true, but even if the answer to that question were true, the configuration must be overridable with e.g. "git stash --no-gpg-sign", explicitly from the command line. Until that happens, the series with 2af2ef3c (Add the commit.gpgsign option to sign all commits, 2013-11-05) cannot be merged to 'master'.

A series that lets you specify positives from the command line without any sticky configuration variable, i.e. these patches, do not have to wait for that to happen. So this series should come first and then the "commit.gpgsign" ones can be rebased on top of this series, I would think.