Repository navigation
sideband: skip unrecognized allowControlCharacters keywords - #2261
thomasbachem wants to merge 1 commit into
Conversation
Since 1289144 (sideband: add options to allow more control sequences to be passed through, 2026-03-05), the value of sideband.allowControlCharacters is a comma-separated list of keywords. When the parser meets a keyword it does not know, it warns but stays on that keyword, so the warning repeats forever. As the setting is read whenever a transport is set up, a typo like "colour", a list written as "color, cursor" with a space, or a keyword that only a newer version of Git knows is enough to make every fetch, push, clone and ls-remote hang this way. Move on to the next keyword after the warning, and name only the unrecognized keyword in it, not the rest of the list. Assisted-by: Claude Opus 5.5 Signed-off-by: Thomas Bachem <mail@thomasbachem.com>
|
/preview |
|
Preview email sent as pull.2261.git.1792148387473.gitgitgadget@gmail.com |
|
/submit |
|
Submitted as pull.2261.git.1792154374653.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Tuomas Ahola wrote on the Git mailing list (how to reply to this email): "Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com> wrote:
> + warning(_("unrecognized value for '%s': '%.*s'"),
> + var, (int)(end - value), value);
> + value = end + !!*end;
> + }
Reading CodingGuidelines, it seems that `!!` is a construct we would
like to avoid:
- Some clever tricks, like using the !! operator with arithmetic
constructs, can be extremely confusing to others. Avoid them,
unless there is a compelling reason to use them.
--Tuomas |
|
User |
|
Thomas Bachem wrote on the Git mailing list (how to reply to this email): Tuomas Ahola <taahol@utu.fi> wrote:
>> + value = end + !!*end;
>
> Reading CodingGuidelines, it seems that `!!` is a construct we would
> like to avoid:
I wrote it this way to match skip_prefix_in_csv() a few lines above,
which steps past the comma the same way:
*out = value + !!*value;
so the two places in this parser read alike. Happy to spell it out as a
conditional in a v2 if that's preferred, though.
Thomas |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): Tuomas Ahola <taahol@utu.fi> writes:
> "Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com> wrote:
>
>> + warning(_("unrecognized value for '%s': '%.*s'"),
>> + var, (int)(end - value), value);
>> + value = end + !!*end;
>> + }
>
> Reading CodingGuidelines, it seems that `!!` is a construct we would
> like to avoid:
>
> - Some clever tricks, like using the !! operator with arithmetic
> constructs, can be extremely confusing to others. Avoid them,
> unless there is a compelling reason to use them.
>
> --Tuomas
But here it is compelling. You want to normalize random byte into 0
or 1, depending on "is it 0 or non-zero?" criteria, and it certainly
is easier to read than (*end ? 1 : 0).
Quite honestly, I do not think !! qualifies as "clever trick that is
confusing" anymore. Perhaps putting the rule there is misguided.
Thanks.
|
|
Tuomas Ahola wrote on the Git mailing list (how to reply to this email): Junio C Hamano <gitster@pobox.com> wrote:
> Tuomas Ahola <taahol@utu.fi> writes:
>
> > "Thomas Bachem via GitGitGadget" <gitgitgadget@gmail.com> wrote:
> >
> >> + warning(_("unrecognized value for '%s': '%.*s'"),
> >> + var, (int)(end - value), value);
> >> + value = end + !!*end;
> >> + }
> >
> > Reading CodingGuidelines, it seems that `!!` is a construct we would
> > like to avoid:
> >
> > - Some clever tricks, like using the !! operator with arithmetic
> > constructs, can be extremely confusing to others. Avoid them,
> > unless there is a compelling reason to use them.
> >
> > --Tuomas
>
> But here it is compelling. You want to normalize random byte into 0
> or 1, depending on "is it 0 or non-zero?" criteria, and it certainly
> is easier to read than (*end ? 1 : 0).
>
Uh, of course. Sorry for my mental short-circuit.
> Quite honestly, I do not think !! qualifies as "clever trick that is
> confusing" anymore. Perhaps putting the rule there is misguided.
>
> Thanks.
Okay. I'll consider writing a patch to drop that from CodingGuidelines. |
|
This patch series was integrated into seen via git@0a4a65c. |
|
This branch is now known as |
|
There was a status update in the "New Topics" section about the branch The configuration parser for 'sideband.allowControlCharacters' has been updated to correctly advance past unrecognized values, preventing an infinite loop when an unknown control character keyword is encountered. Needs review. cf. <xmqq8q3xh98n.fsf@gitster.g> source: <pull.2261.git.1792154374653.gitgitgadget@gmail.com> |
|
There was a status update in the "Cooking" section about the branch The configuration parser for 'sideband.allowControlCharacters' has been updated to correctly advance past unrecognized values, preventing an infinite loop when an unknown control character keyword is encountered. Needs review. cf. <xmqq8q3xh98n.fsf@gitster.g> source: <pull.2261.git.1792154374653.gitgitgadget@gmail.com> |
Cc: Johannes Schindelin Johannes.Schindelin@gmx.de
Cc: Junio C Hamano gitster@pobox.com
cc: Tuomas Ahola taahol@utu.fi