Re: Clarify the meaning of "character" in the documentation

> Dragan Simic <dsimic@manjaro.org> writes:
>> On 2024-03-05 16:32, Junio C Hamano wrote:
>>> "Kristoffer Haugsbakk" <code@khaugsbakk.name> writes:
>>>> I think this is more about `git config --add` not doing any
>>>> validation. It just sets things. You can do `git config --add
>>>> core.commentChar 'ffd'` and get the same effect.
>>> As you said, we should document core.commentChar as limited to an
>>> ASCII character, at least as a short term solution.
>>> I personally do not see a reason, however, why we need to be limited
>>> to a single byte, though.  If a patch cleanly implements to allow us
>>> to use any one-or-more-byte sequence as core.commentChar, I do not
>>> offhand see a good reason to reject it---it would be fully backward
>>> compatible and allows you to use a UTF-8 charcter outside ASCII, as
>>> well as "//" and the like.
>> 
>> May I ask why would we want the comment character to possibly be
>> a multibyte character?  I mean, I support localization, to make it all
>> easier for the users who opt not to use English, but wouldn't allowing
>> multibyte characters for the comment character simply be a bit 
>> unneeded?
>> 
>> Maybe I'm missing something?
> 
> That's not a question for me ;-).
> 
> It is not my personal itch, so I haven't done anything to make the
> commentChar take more than one byte.  But if it is somebody else's
> itch, I do not see a reason why we should forbid them from
> scratching.  If the setting seeps through across repository
> boundaries, that may create a compatibility issue and that by itself
> might be such a reason.  If it greatly makes the code more complex,
> that may be another reason you can use to argue against adding such
> a "feature".  If it makes the semantics of what "a comment string"
> is and how they are added and stripped at various stages of
> processing commit log messages fuzzy and harder to document and
> understand, that might be another reason.  I however do not think
> any of these to be true.  Maybe I am overly optimistic.  I haven't
> looked deeply into the code around commentChar for quite some time.