On 2024-03-05 17:38, Junio C Hamano wrote:
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.
Yes, there are quite a few possible obstacles. As I replied to
Kristoffer
a bit earlier, I see this more as a programming exercise. Of course,
unless someone really needs it as a new feature, in which case they will
probably need to overcome all those obstacles. :)
