Dragan Simic <dsimic@xxxxxxxxxxx> writes: > On 2024-03-05 16:32, Junio C Hamano wrote: >> "Kristoffer Haugsbakk" <code@xxxxxxxxxxxxxxx> 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.
