Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Make 'git config list --type=<X>' parse and filter types #2044

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
derrickstolee wants to merge 13 commits into from
+331 −88
Closed

Make 'git config list --type=<X>' parse and filter types #2044

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
bca83d8
config: move show_all_config()
derrickstolee Feb 10, 2026
93c94a1
config: add 'gently' parameter to format_config()
derrickstolee Feb 13, 2026
2b2a325
config: make 'git config list --type=<X>' work
derrickstolee Feb 10, 2026
4835ee5
config: format int64s gently
derrickstolee Feb 13, 2026
24eb757
config: format bools gently
derrickstolee Feb 13, 2026
02849ca
config: format bools or ints gently
derrickstolee Feb 13, 2026
9f06db2
config: format bools or strings in helper
derrickstolee Feb 13, 2026
d198c23
config: format paths gently
derrickstolee Feb 13, 2026
7568a0b
config: format expiry dates quietly
derrickstolee Feb 13, 2026
d98966f
color: add color_parse_quietly()
derrickstolee Feb 13, 2026
078065c
config: format colors quietly
derrickstolee Feb 13, 2026
76fc767
config: restructure format_config()
derrickstolee Feb 13, 2026
3c32c03
config: use an enum for type
derrickstolee Feb 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
color: add color_parse_quietly() 
When parsing colors, a failed parse leads to an error message due to the
result returning error(). To allow for quiet parsing, create
color_parse_quietly(). This is in contrast to an ..._gently() version
because the original does not die(), so both options are technically
'gentle'.

To accomplish this, convert the implementation of color_parse_mem() into
a static color_parse_mem_1() helper that adds a 'quiet' parameter. The
color_parse_quietly() method can then use this. Since it is a near
equivalent to color_parse(), move that method down in the file so they
can be nearby while also appearing after color_parse_mem_1().

Signed-off-by: Derrick Stolee <stolee@gmail.com>
  • Loading branch information
@derrickstolee
derrickstolee committed Feb 23, 2026
commit d98966f53a4f201be041c4e8a83ed549f64aa404
25 changes: 18 additions & 7 deletions 25 color.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,11 +223,6 @@ static int parse_attr(const char *name, size_t len)
return -1;
Copy link
Copy Markdown

@gitgitgadget gitgitgadget bot Feb 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):

On Fri, Feb 13, 2026 at 11:55:16PM +0000, Derrick Stolee via GitGitGadget wrote:
> diff --git a/color.c b/color.c
> index 07ac8c9d40..ec8872d2dd 100644
> --- a/color.c
> +++ b/color.c
> @@ -264,7 +259,8 @@ static int color_empty(const struct color *c)
>  	return c->type <= COLOR_NORMAL;
>  }
>  
> -int color_parse_mem(const char *value, int value_len, char *dst)
> +static int color_parse_mem_1(const char *value, int value_len,
> +			     char *dst, int gently)
>  {
>  	const char *ptr = value;
>  	int len = value_len;
> @@ -365,10 +361,25 @@ int color_parse_mem(const char *value, int value_len, char *dst)
>  	OUT(0);
>  	return 0;
>  bad:
> -	return error(_("invalid color value: %.*s"), value_len, value);
> +	return gently ? -1 : error(_("invalid color value: %.*s"), value_len, value);
>  #undef OUT
>  }

As far as I can see this isn't really about whether or not the function
should be gentle. It's rather whether or not the function should print
an error message when it sees an error.

So should we rename the parameter to `quiet`?

>  
> +int color_parse_mem(const char *value, int value_len, char *dst)
> +{
> +	return color_parse_mem_1(value, value_len, dst, 0);
> +}
> +
> +int color_parse(const char *value, char *dst)
> +{
> +	return color_parse_mem(value, strlen(value), dst);
> +}
> +
> +int color_parse_gently(const char *value, char *dst)
> +{
> +	return color_parse_mem_1(value, strlen(value), dst, 1);
> +}

And if so, this should probably be called `color_parse_quiet()`.

Patrick

Copy link
Copy Markdown

@gitgitgadget gitgitgadget bot Feb 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

Patrick Steinhardt <ps@pks.im> writes:

> On Fri, Feb 13, 2026 at 11:55:16PM +0000, Derrick Stolee via GitGitGadget wrote:
>> diff --git a/color.c b/color.c
>> index 07ac8c9d40..ec8872d2dd 100644
>> --- a/color.c
>> +++ b/color.c
>> @@ -264,7 +259,8 @@ static int color_empty(const struct color *c)
>>  	return c->type <= COLOR_NORMAL;
>>  }
>>  
>> -int color_parse_mem(const char *value, int value_len, char *dst)
>> +static int color_parse_mem_1(const char *value, int value_len,
>> +			     char *dst, int gently)
>>  {
>>  	const char *ptr = value;
>>  	int len = value_len;
>> @@ -365,10 +361,25 @@ int color_parse_mem(const char *value, int value_len, char *dst)
>>  	OUT(0);
>>  	return 0;
>>  bad:
>> -	return error(_("invalid color value: %.*s"), value_len, value);
>> +	return gently ? -1 : error(_("invalid color value: %.*s"), value_len, value);
>>  #undef OUT
>>  }
>
> As far as I can see this isn't really about whether or not the function
> should be gentle. It's rather whether or not the function should print
> an error message when it sees an error.

Do you mean that this error() call is not die(), the flag does not
fit the usual "gently" criteria?  In other words, should we make
this call die() if we call it "gently"?

>
> So should we rename the parameter to `quiet`?
>
>>  
>> +int color_parse_mem(const char *value, int value_len, char *dst)
>> +{
>> +	return color_parse_mem_1(value, value_len, dst, 0);
>> +}
>> +
>> +int color_parse(const char *value, char *dst)
>> +{
>> +	return color_parse_mem(value, strlen(value), dst);
>> +}
>> +
>> +int color_parse_gently(const char *value, char *dst)
>> +{
>> +	return color_parse_mem_1(value, strlen(value), dst, 1);
>> +}
>
> And if so, this should probably be called `color_parse_quiet()`.
>
> Patrick

Copy link
Copy Markdown

@gitgitgadget gitgitgadget bot Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Derrick Stolee wrote on the Git mailing list (how to reply to this email):

On 2/17/26 11:20 AM, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> >> On Fri, Feb 13, 2026 at 11:55:16PM +0000, Derrick Stolee via GitGitGadget wrote:
>>> diff --git a/color.c b/color.c
>>> index 07ac8c9d40..ec8872d2dd 100644
>>> --- a/color.c
>>> +++ b/color.c
>>> @@ -264,7 +259,8 @@ static int color_empty(const struct color *c)
>>>   	return c->type <= COLOR_NORMAL;
>>>   }
>>>   >>> -int color_parse_mem(const char *value, int value_len, char *dst)
>>> +static int color_parse_mem_1(const char *value, int value_len,
>>> +			     char *dst, int gently)
>>>   {
>>>   	const char *ptr = value;
>>>   	int len = value_len;
>>> @@ -365,10 +361,25 @@ int color_parse_mem(const char *value, int value_len, char *dst)
>>>   	OUT(0);
>>>   	return 0;
>>>   bad:
>>> -	return error(_("invalid color value: %.*s"), value_len, value);
>>> +	return gently ? -1 : error(_("invalid color value: %.*s"), value_len, value);
>>>   #undef OUT
>>>   }
>>
>> As far as I can see this isn't really about whether or not the function
>> should be gentle. It's rather whether or not the function should print
>> an error message when it sees an error.
> > Do you mean that this error() call is not die(), the flag does not
> fit the usual "gently" criteria?  In other words, should we make
> this call die() if we call it "gently"?

This is an interesting case where the existing color parsing logic is
not following the typical pattern that uses die() on a failed parse.

If we want to change the behavior to die() later, then that could be
considered, though I don't want to consider the ramifications right now.

I think the easiest "local" fix is to use the 'quiet' way, though it adds
some asymmetry in the config code in how it uses the 'gently' parameter.
Let me give this a try in the next version so we can see how it feels.

Thanks,
-Stolee

Copy link
Copy Markdown

@gitgitgadget gitgitgadget bot Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

Derrick Stolee <stolee@gmail.com> writes:

>> Do you mean that this error() call is not die(), the flag does not
>> fit the usual "gently" criteria?  In other words, should we make
>> this call die() if we call it "gently"?
>
> This is an interesting case where the existing color parsing logic is
> not following the typical pattern that uses die() on a failed parse.

I see.  I personally would view that an existing bug worth fixing,
but I ...

> If we want to change the behavior to die() later, then that could be
> considered, though I don't want to consider the ramifications right now.

... agree with you that it should be fixed outside the scope of this
topic.

> I think the easiest "local" fix is to use the 'quiet' way, though it adds
> some asymmetry in the config code in how it uses the 'gently' parameter.

Or, just add comments to the function that takes gently but does not
die() to warn those who would add new callers.  They can pass
gently=1 if they want to handle the errors themselves and keep it
that way.  If they want the function to die, well they have to wait
until the function is fixed to behave like everybody else.

}

int color_parse(const char *value, char *dst)
{
return color_parse_mem(value, strlen(value), dst);
}

/*
* Write the ANSI color codes for "c" to "out"; the string should
* already have the ANSI escape code in it. "out" should have enough
Expand Down Expand Up @@ -264,7 +259,8 @@ static int color_empty(const struct color *c)
return c->type <= COLOR_NORMAL;
}

int color_parse_mem(const char *value, int value_len, char *dst)
static int color_parse_mem_1(const char *value, int value_len,
char *dst, int quiet)
{
const char *ptr = value;
int len = value_len;
Expand Down Expand Up @@ -365,10 +361,25 @@ int color_parse_mem(const char *value, int value_len, char *dst)
OUT(0);
return 0;
bad:
return error(_("invalid color value: %.*s"), value_len, value);
return quiet ? -1 : error(_("invalid color value: %.*s"), value_len, value);
#undef OUT
}

int color_parse_mem(const char *value, int value_len, char *dst)
{
return color_parse_mem_1(value, value_len, dst, 0);
}

int color_parse(const char *value, char *dst)
{
return color_parse_mem(value, strlen(value), dst);
}

int color_parse_quietly(const char *value, char *dst)
{
return color_parse_mem_1(value, strlen(value), dst, 1);
}

enum git_colorbool git_config_colorbool(const char *var, const char *value)
{
if (value) {
Expand Down
1 change: 1 addition & 0 deletions 1 color.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -118,6 +118,7 @@ bool want_color_fd(int fd, enum git_colorbool var);
* terminal.
*/
int color_parse(const char *value, char *dst);
int color_parse_quietly(const char *value, char *dst);
int color_parse_mem(const char *value, int len, char *dst);

/*
Expand Down
Morty Proxy This is a proxified and sanitized view of the page, visit original site.