Re: [PATCH] git-gui: remove lines starting with the comment character

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Feb 3, 2021, 17:48 UTC
Message-ID: <CAPig+cTQaPTNnGcd583B=xoVUR1qPb372Y_x9szROfMcA5h+tA@mail.gmail.com>
In-Reply-To: <fdfe1661-463b-fc18-02cc-4c6e22ce0463@kdbg.org>

On Wed, Feb 3, 2021 at 12:35 PM Johannes Sixt <j6t@kdbg.org> wrote:

Show 17 quoted lines

> Am 02.02.21 um 21:03 schrieb Pratyush Yadav:
> > The comment character is specified by the config variable
> > 'core.commentchar'. Any lines starting with this character is considered
> > a comment and should not be included in the final commit message.
> >
> > Teach git-gui to filter out lines in the commit message that start with
> > the comment character. If the config is not set, '#' is taken as the
> > default.
>
> This is WRONG. Git GUI is that: a GUI, it's all about WYSIWYG. If you do
> not give sufficient unambiguous visual clue to the user that certain
> lines will be ignored, you cannot ignore them.
>
> Perhaps what you are really only interested in is to remove the list of
> conflicted files after a merge conflict? Then the correct way to proceed
> would be to sanitize the contents of .git/MERGE_MSG before it is
> inserted into the edit box.

This is indeed the case I run into which is annoying because the commented-out list of conflicted files does not get removed when git-gui performs the actual commit.

However, although what you propose here seems superficially enticing, it doesn't mirror the behavior of git-commit itself when launching an editor, in which case the unsanitized file (containing the commented-out conflicted file list) is loaded into the editor verbatim, and it is only sanitized when the edit session is finished. The important difference is that extra text is added to the edit buffer telling the user explicitly that "lines beginning with '#' will be ignored".

So, perhaps one way forward is for Pratyush to emulate that behavior and insert some text into the edit box saying "lines beginning with '#' will be ignored", or add a label above or below the edit box stating the same. (Of course, the actual displayed comment-character should be determined dynamically.)