Re: [PATCH v2 16/16] config: allow multi-byte core.commentChar
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 26, 2024, 22:10 UTC
- Message-ID
- <xmqq8r247igg.fsf@gitster.g>
- In-Reply-To
- <20240315081041.GA1753560@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 24 quoted lines
> So anyway, adapting your original suggestion based on discussion in the > thread, maybe squash in (to the final patch): > > diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt > index c86b8c8408..c5a8033df9 100644 > --- a/Documentation/config/core.txt > +++ b/Documentation/config/core.txt > @@ -523,9 +523,8 @@ core.commentChar:: > Commands such as `commit` and `tag` that let you edit > messages consider a line that begins with this character > commented, and removes them after the editor returns > - (default '#'). Note that this option can take values larger than > - a byte (whether a single multi-byte character, or you > - could even go wild with a multi-character sequence). > + (default '#'). Note that this variable can be a string like > + `//` or `⁑⁕⁑`; it doesn't have to be a single ASCII character. > + > If set to "auto", `git-commit` would select a character that is not > the beginning character of any line in existing commit messages. > > > 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. ;)
It has been 10 days since this discussion petered out.
My preference is to introduce core.commentString to avoid confusion coming from an older Git using the first-byte of a multi-byte string, or dying upon reading a configuration file meant for a newer Git, and then let core.commentString override core.commentChar, but I would prefer to see the discussion participants to raise their opinions and reach a conclusion.
Thanks.