From: Jeff King <peff@peff.net>
To: Mehul Jain <mehul.jain2029@gmail.com>
Cc: git@vger.kernel.org, Austin English <austinenglish@gmail.com>
Subject: Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable
Date: Thu, 26 May 2016 12:59:46 -0400 [thread overview]
Message-ID: <20160526165946.GA18383@sigill.intra.peff.net> (raw)
In-Reply-To: <20160526130647.27001-2-mehul.jain2029@gmail.com>
On Thu, May 26, 2016 at 06:36:46PM +0530, Mehul Jain wrote:
> diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
> index 03f9580..f39f800 100644
> --- a/Documentation/git-log.txt
> +++ b/Documentation/git-log.txt
> @@ -196,6 +196,10 @@ log.showRoot::
> `git log -p` output would be shown without a diff attached.
> The default is `true`.
>
> +log.showSignature::
> + If `true`, `git log` and `git show` will act as if `--show-signature`
> + option was passed to them.
This should be:
...if the `--show-signature` option was...
or:
...if `--show-signature` was...
Either is correct; you just need an article when not referring directly
to the option by its name.
The documentation here mentions "log" and "show". But I think this will
affect other programs, too, including "whatchanged" and "reflog". Those
ones are probably good, but the documentation is a little misleading (I
think other options just say "git-log and related commands" or
something).
I thought at first it would affect format-patch, too, which would be
weird. But in that command we _do_ parse the variable and end up setting
default_show_signature, but we never call cmd_log_init_defaults(), which
is what copies that value into the rev_info struct. That's kind of a
weird way to split it, but it's certainly not something you introduced
here.
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 128ba93..36be9a1 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -890,6 +890,25 @@ test_expect_success GPG 'log --graph --show-signature for merged tag' '
> grep "^| | gpg: Good signature" actual
> '
>
> +test_expect_success GPG 'log.showsignature=true behaves like --show-signature' '
> + git checkout -b test_sign master &&
> + echo foo >foo &&
> + git add foo &&
> + git commit -S -m signed_commit &&
> + test_config log.showsignature true &&
> + git log -1 signed >actual &&
> + test_i18ngrep "gpg: Signature made" actual &&
> + test_i18ngrep "gpg: Good signature" actual
> +'
You can see in the context that we do not use test_i18ngrep for finding
gpg output in existing tests. I'm not sure if the new tests should be
consistent, or if they should be changed to use test_i18ngrep. I don't
think it's actually doing anything here, though. It's used with a
git-specific GETTEXT_POISON flag that tweaks the output generated by
git, but not by sub-programs like gpg.
> +test_expect_success GPG '--show-signature overrides log.showsignature=false' '
> + test_when_finished "git reset --hard && git checkout master" &&
> + git config log.showsignature false &&
Should this be test_config?
> +test_expect_success GPG 'log.showsignature behaves like --show-signature' '
> + git config log.showsignature true &&
Ditto here.
-Peff
next prev parent reply other threads:[~2016-05-26 16:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-26 13:06 [RFC/PATCH 0/2] Introduce "log.showSignature" config variable Mehul Jain
2016-05-26 13:06 ` [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable Mehul Jain
2016-05-26 13:42 ` Remi Galan Alfonso
2016-05-26 15:04 ` Mehul Jain
2016-05-26 15:43 ` Remi Galan Alfonso
2016-05-26 16:06 ` Mehul Jain
2016-05-27 4:01 ` Pranit Bauva
2016-05-26 16:59 ` Jeff King [this message]
2016-05-27 6:04 ` Mehul Jain
2016-05-26 13:06 ` [RFC/PATCH 2/2] log: add "--no-show-signature" command line option Mehul Jain
2016-05-26 16:32 ` Jeff King
2016-05-26 16:42 ` Mehul Jain
2016-05-26 17:01 ` Jeff King
2016-05-26 17:22 ` Junio C Hamano
2016-05-27 6:08 ` Mehul Jain
2016-05-27 17:37 ` Junio C Hamano
2016-05-27 17:48 ` Jeff King
2016-05-27 2:55 ` [RFC/PATCH 0/2] Introduce "log.showSignature" config variable Austin English
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160526165946.GA18383@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=austinenglish@gmail.com \
--cc=git@vger.kernel.org \
--cc=mehul.jain2029@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).