Subject: Re: [PATCH v2 16/16] config: allow multi-byte core.commentChar

From: Junio C Hamano <[email-masked]>
Date: Fri, 15 Mar 2024 08:40:56 -0700

Jeff King <[email-masked]> writes:

> +	(default '#'). Note that this variable can be a string like
> +	`//` or `⁑⁕⁑`; it doesn't have to be a single ASCII character.

Looking good.

> That's assuming we don't want to go the commentString route, which would
> require a bit more re-working of the patch. I'm also open to a more
> clever or pretty multi-byte example if we have one. ;)

Adding core.commentString can be done long after the dust settles
and I would expect that most of the changes in the patch would not
have to be updated.  The parts that use comment_line_str variable do
not have to change, the documentation needs "core.commentString is a
synonym for core.commentChar, the latter of which is understood by
older versions of Git (but they may use only the first byte of the
string)" or something, but other than that, the existing text after
this patch does not have to be updated.  If we add a proper synonym
support to the config machinery, that would be a sizable project,
but otherwise it would be just another "if (!strcmp()) var = val".

Stepping back a bit, one thing that we do need to mention in this
round is what happens when you use multi-byte sequence and have it
accessed by existing versions of Git.  "use only the first byte" I
wrote above came out of thin air without experimenting or reading
the code, but something like that ought to be part of the "Note
that" paragraph above.

	(default '#'). Note that this variable can be a string like
	`//` or `⁑⁕⁑`; it doesn't have to be a single ASCII character.
	Also note that older versions of Git used only the first byte
	(not necessarily a character) of the value of this variable,
	so you may want to be careful if you plan to use versions of
	Git older than 2.45.

or something like that, perhaps.