Re: [PATCH] Add .gitconfig variable commit.gpg-sign

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 23, 2013, 19:25 UTC
Message-ID: <7v1ua1hwx6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAASwCXdhgNPzm51MfWTCTNYQwT0gC-UbV7xTNGcXhs6k9f4wsQ@mail.gmail.com>

Joel Jacobson <joel@trustly.com> writes:

Show 13 quoted lines

> On Tue, Apr 23, 2013 at 6:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I would consider such use of "git -c key=val" a last-resort escape
>> hatch to work around broken commands that do not implement a proper
>> escape hatch designed in to help users, unless the "key" is for
>> something very obscure and not meant for every-day use (read: not
>> deserving a proper command line override).
>
> Agreed.
>
> We already have --gpg-sign[=<keyid>], so I suggest --no-gpg-sign to
> override commit.gpgsign.
>
> Sounds good?

Yup.

And then we would need to add the same option to existing callers of "git commit" (such as "git rebase") to pass it down the callchain.

But stepping back a bit, I have a suspicion that your upstream project _only_ cares about what you feed them (either by pushing your work yourself to them, or telling them to pull from your repository). There is no reason for you to be constantly signing your commits you make during your exploratory development that you may throw-away in the end.

It _might_ be a better option to just teach "-S" option to "git rebase" that tells it to replay all the commits with "commit -S", instead of adding commit.gpgSign configuration.