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

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.

Signed-off-by: Pratyush Yadav <redacted>
---
 lib/commit.tcl | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/lib/commit.tcl b/lib/commit.tcl
index 11379f8..3c3035f 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl

@@ -209,6 +209,28 @@ You must stage at least 1 file before you can commit.
 	#
 	set msg [string trim [$ui_comm get 1.0 end]]
 	regsub -all -line {[ \t\r]+$} $msg {} msg
+
+	# Remove lines starting with the comment character.
+	set comment_char [get_config core.commentchar]
+	if {[string length $comment_char] > 1} {
+		error_popup [mc "core.commitchar should only be one character."]
+		unlock_index
+		return
+	}
+
+	if {$comment_char eq {}} {
+		set comment_char "#"
+	}
+
+	# If the comment character is not alphabetical, then we need to escape it
+	# with a backslash to make sure it is not interpreted as a special character
+	# in the regex.
+	if {![string is alpha $comment_char]} {
+		set comment_char "\\$comment_char"
+	}
+
+	regsub -all -line "$comment_char.*(\\n|\\Z)" $msg {} msg
+
 	if {$msg eq {}} {
 		error_popup [mc "Please supply a commit message.

--

2.30.0

On Tue, Feb 2, 2021 at 3:07 PM Pratyush Yadav [off-list ref] wrote:

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.

Thanks. This shortcoming has bugged me for a long time. A few comments below...

This regular expression is too loose. It will incorrectly change:

    line one
    line # two
    # line three
    line four

into:

    line one
    line
    line four

You could fix it by anchoring the start of the match while being
careful not to lose the newline at the start of line. Perhaps like
this:

    regsub -all -line "(^|\\A)$comment_char.*(\\n|\\Z)" $msg {} msg

However, an even better approach than doing this manipulation manually
might be to pass the commit message through `git stripspace
--strip-comments` which will do the exact normalization that Git
itself does. That way, you don't have to worry about weird corner
cases. Also, using git-stripspace may allow you to get rid of the
existing `trim` and `regsub` which precede the new code you added.

On 02/02/21 05:26PM, Eric Sunshine wrote:

On Tue, Feb 2, 2021 at 3:07 PM Pratyush Yadav [off-list ref] wrote:

quoted

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.

Thanks. This shortcoming has bugged me for a long time. A few comments below...

quoted

Signed-off-by: Pratyush Yadav <redacted>
---

diff --git a/lib/commit.tcl b/lib/commit.tcl

@@ -209,6 +209,28 @@ You must stage at least 1 file before you can commit.
        set msg [string trim [$ui_comm get 1.0 end]]
        regsub -all -line {[ \t\r]+$} $msg {} msg
+
+       # Remove lines starting with the comment character.
+       set comment_char [get_config core.commentchar]
+       if {[string length $comment_char] > 1} {
+               error_popup [mc "core.commitchar should only be one character."]
+               unlock_index
+               return
+       }
+
+       if {$comment_char eq {}} {
+               set comment_char "#"
+       }
+
+       # If the comment character is not alphabetical, then we need to escape it
+       # with a backslash to make sure it is not interpreted as a special character
+       # in the regex.
+       if {![string is alpha $comment_char]} {
+               set comment_char "\\$comment_char"
+       }
+
+       regsub -all -line "$comment_char.*(\\n|\\Z)" $msg {} msg

This regular expression is too loose. It will incorrectly change:

    line one
    line # two
    # line three
    line four

into:

    line one
    line
    line four

You could fix it by anchoring the start of the match while being
careful not to lose the newline at the start of line. Perhaps like
this:

    regsub -all -line "(^|\\A)$comment_char.*(\\n|\\Z)" $msg {} msg

Good catch!

However, an even better approach than doing this manipulation manually
might be to pass the commit message through `git stripspace
--strip-comments` which will do the exact normalization that Git
itself does. That way, you don't have to worry about weird corner
cases. Also, using git-stripspace may allow you to get rid of the
existing `trim` and `regsub` which precede the new code you added.

This is exactly what I was looking for when I was writing the patch but 
didn't manage to find it. Will re-roll. Thanks.

-- 
Regards,
Pratyush Yadav

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.

You cannot just throw away what the user has typed into the edit box
without warning. How would you make it possible to insert text that
happens to begin with the comment character of the day?

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.

-- Hannes

On Wed, Feb 3, 2021 at 12:35 PM Johannes Sixt [off-list ref] wrote:

Am 02.02.21 um 21:03 schrieb Pratyush Yadav:

quoted

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.)

On Wed, Feb 3, 2021 at 12:48 PM Eric Sunshine [off-list ref] wrote:

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.)

Even more fancy would be to add a checkbox below the edit field which
both enables/disables the "stripspace" behavior and allows the user to
specify the comment-character. For instance:

    [x] ignore lines beginning with [#]

where [x] is the checkbox and [#] is a text field in which the user
can type the comment-character.

For convenience, the checkbox would be checked by default, and the
comment-character would default to the user's configured
comment-character or "#".

On 03/02/21 12:48PM, Eric Sunshine wrote:

On Wed, Feb 3, 2021 at 12:35 PM Johannes Sixt [off-list ref] wrote:

quoted

Am 02.02.21 um 21:03 schrieb Pratyush Yadav:

quoted

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.

While this patch also fixes the merge conflict message case, it was in 
fact prompted by [0], which talks about comments in the commit message 
template. This is likely useful information that we don't want to hide 
from the user.

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".

I agree. 
 

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.)

This would be a nice addition. Will see which approach looks best.

[0] https://github.com/prati0100/git-gui/issues/51

-- 
Regards,
Pratyush Yadav

Am 03.02.21 um 18:58 schrieb Eric Sunshine:

On Wed, Feb 3, 2021 at 12:48 PM Eric Sunshine [off-list ref] wrote:

quoted

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.)

Even more fancy would be to add a checkbox below the edit field which
both enables/disables the "stripspace" behavior and allows the user to
specify the comment-character. For instance:

    [x] ignore lines beginning with [#]

where [x] is the checkbox and [#] is a text field in which the user
can type the comment-character.

For convenience, the checkbox would be checked by default, and the
comment-character would default to the user's configured
comment-character or "#".

While I'm not thrilled by this solution, it's probably the only sensible
way forward. We would have to place the checkbox above the edit field,
where there's still some space; otherwise, it takes away vertical space,
and that I really prefer to use for the commit message and the patch text.

I don't think, though, that we need an edit field to change the comment
character. It's a fairly stable setting, and as long as there's a
preference for it and it's synchronized into the checkbox caption, it is
fine, IMO.

-- Hannes