Re: [PATCH 0/7] Flags and config to sign pushes by default

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 0/7] Flags and config to sign pushes by default

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:06:13

Dave Borowitz [off-list ref] writes:
Is there a common utility function that does what we want? Basically
git_config_maybe_bool but not specifically about configs.
Interesting.  git_config_maybe_bool() and its friends take the usual
(name, value) and pretend to be part of the "config" family, primarily
because that was where they came from.

But they do not really care about "name", which is used for error
reporting and that is what makes them look very specific to the
config subsystem.

I did a quick grep of git_config_maybe_bool() and I _think_ all
callers are prepared to handle errors themselves, so it might be a
good direction to go in the longer term to drop "name" and rename
the function to git_parse_maybe_bool() or something, and make these
callers use that.

In the shorter term, at least we should be able to introduce
git_parse_maybe_bool() that does not take "name", use that as a
helper to implement git_config_maybe_bool(), so that the existing
callers of git_config_maybe_bool() does not have to change.  And
that new helper can be used as your "Basically it, but not
specifically about configs".

Re: [PATCH 0/7] Flags and config to sign pushes by default

From: Dave Borowitz <hidden>
Date: 2016-06-15 23:06:13

On Mon, Aug 17, 2015 at 3:54 PM, Junio C Hamano [off-list ref] wrote:
In the shorter term, at least we should be able to introduce
git_parse_maybe_bool() that does not take "name", use that as a
helper to implement git_config_maybe_bool(), so that the existing
callers of git_config_maybe_bool() does not have to change.  And
that new helper can be used as your "Basically it, but not
specifically about configs".
Will do, thanks for the suggestion.

Slight digression for a question that came up during reworking the
series: would it be reasonable to rewrite option parsing in
builtin/send-pack.c to use the options API? That way we can easily
reuse the option callback from builtin/push.c. (It would have some
side effects like making --no-* variants work where they did not
before; I assume that's a good thing, but it's marginally inconsistent
with some other plumbing commands like receive-pack.)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help