git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 7/7] Add a config option push.gpgSign for default signed pushes

From
Dave Borowitz <dborowitz@google.com>
Date
Aug 17, 2015, 18:22 UTC
Message-ID
<CAD0k6qTnJPc+Nh6dck0_Zx9vnyn5YVMCmy3E=7vr8bTpRSppAA@mail.gmail.com>
In-Reply-To
<xmqqy4h9et2m.fsf@gitster.dls.corp.google.com>
On Mon, Aug 17, 2015 at 1:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 36 quoted lines
> Dave Borowitz <dborowitz@google.com> writes:
>
>> ---
>
> Does the lack of sign-off indicate something (like "this is just a
> 'what do people think?' weatherbaloon not yet a serious submission")?
>
>> +push.gpgSign::
>> +     May be set to a boolean value, or the string 'if-possible'. A
>> +     true value causes all pushes to be GPG signed, as if '--signed'
>> +     is passed to linkgit:git-push[1]. The string 'if-possible'
>> +     causes pushes to be signed if the server supports it, as if
>> +     '--signed-if-possible' is passed to 'git push'. A false value
>> +     may override a value from a lower-priority config file. An
>> +     explicit command-line flag always overrides this config option.
>
>> diff --git a/builtin/push.c b/builtin/push.c
>> index 95a67c5..8972193 100644
>> --- a/builtin/push.c
>> +++ b/builtin/push.c
>> @@ -491,6 +491,26 @@ static int git_push_config(const char *k, const char *v, void *cb)
>>       return git_default_config(k, v, NULL);
>>  }
>>
>> +static void set_push_cert_flags_from_config(int *flags)
>> +{
>> +     const char *value;
>> +     /* Ignore config if flags were set from command line. */
>> +     if (*flags & (TRANSPORT_PUSH_CERT_ALWAYS | TRANSPORT_PUSH_CERT_IF_POSSIBLE))
>> +             return;
>
> This looks somewhat strange.  Usually we read from config first and
> then from options, so a git_config() callback shouldn't have to
> worry about what command line option parser did (because it hasn't
> happened yet).  Why isn't the addition to support this new variable
> done inside existing git_push_config() callback function?

The issue is that if both _ALWAYS and _IF_POSSIBLE are set, git_transport_push interprets it as _ALWAYS. But, we are also supposed to prefer explicit command-line options to config values.

Suppose we parsed config first, then options. If the user has push.signed = always and and passes --signed-if-possible, then the end result is (_ALWAYS | _IF_POSSIBLE), aka always, and we've violated "prefer command line options to config values".

I guess the alternative is to have --signed just clear the _IF_POSSIBLE bit in addition to setting the _ALWAYS bit, and vice versa for --signed-if-possible. I am not sure what the end result would be if the user passed a combination of various --signed and --signed-if-possible flags on the command line; maybe that's not worth worrying about.

Show 26 quoted lines
>> +     if (!git_config_get_value("push.gpgsign", &value)) {
>> +             switch (git_config_maybe_bool("push.gpgsign", value)) {
>> +             case 1:
>> +                     *flags |= TRANSPORT_PUSH_CERT_ALWAYS;
>> +                     break;
>> +             default:
>> +                     if (value && !strcmp(value, "if-possible"))
>> +                             *flags |= TRANSPORT_PUSH_CERT_IF_POSSIBLE;
>> +                     else
>> +                             die(_("Invalid value for 'push.gpgsign'"));
>> +             }
>> +     }
>> +}
>> +
>
> maybe_bool() returns 0 for "false" (and its various spellings), 1
> for "true" (and its various spellings) and -1 for "that's not a
> bool".
>
> For "A false value may override a value" to be true, we'd need
>
>                 case 0:
>                         *flags &= ~TRANSPORT_PUSH_CERT_ALWAYS;
>                         break;
>
> or something?

Yes, except unsetting both flags? ~(TRANSPORT_PUSH_CERT_ALWAYS | TRANSPORT_CERT_IF_POSSIBLE)

Previous: Junio C HamanoNext: Junio C Hamano
Message 15 of 32 in “Flags and config to sign pushes by default”
  1. 0/7 Flags and config to sign pushes by defaultDave Borowitz, Aug 13, 2015
  2. 1/7 Documentation/git-push.txt: Document when --signed may failDave Borowitz, Aug 13, 2015
  3. Junio C HamanoAug 14, 2015
  4. Dave BorowitzAug 17, 2015
  5. 2/7 Documentation/git-send-pack.txt: Flow long synopsis lineDave Borowitz, Aug 13, 2015
  6. 3/7 Documentation/git-send-pack.txt: Document --signedDave Borowitz, Aug 13, 2015
  7. 4/7 gitremote-helpers.txt: Document pushcert optionDave Borowitz, Aug 13, 2015
  8. 5/7 transport: Remove git_transport_options.push_certDave Borowitz, Aug 13, 2015
  9. Junio C HamanoAug 14, 2015
  10. 6/7 Support signing pushes iff the server supports itDave Borowitz, Aug 13, 2015
  11. Junio C HamanoAug 14, 2015
  12. Dave BorowitzAug 19, 2015
  13. 7/7 Add a config option push.gpgSign for default signed pushesDave Borowitz, Aug 13, 2015
  14. Junio C HamanoAug 17, 2015
  15. Dave BorowitzAug 17, 2015
  16. Junio C HamanoAug 17, 2015
  17. Junio C HamanoAug 17, 2015
  18. Dave BorowitzAug 17, 2015
  19. Chris PackhamAug 14, 2015
  20. Junio C HamanoAug 14, 2015
  21. Dave BorowitzAug 14, 2015
  22. Dave BorowitzAug 14, 2015
  23. Junio C HamanoAug 14, 2015
  24. Dave BorowitzAug 14, 2015
  25. Junio C HamanoAug 14, 2015
  26. Junio C HamanoAug 17, 2015
  27. Dave BorowitzAug 17, 2015
  28. Junio C HamanoAug 17, 2015
  29. Dave BorowitzAug 17, 2015
  30. Junio C HamanoAug 17, 2015
  31. Dave BorowitzAug 17, 2015
  32. Junio C HamanoAug 17, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.