Community
Participate
Working Groups
When commentChar=auto is enabled, lines starting with '#' in the commit message input textbox are colored green, even though they are not comments. This behavior might confuse users. I see two solutions: 1. Don't color in the input textbox at all. This is also the behavior of c-git and git gui. 2. Evaluate the setting for commentChar and color the lines accordingly.
Indeed, if there is a non-empty commit message and the setting is "auto", it should be evaluated.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/194318
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/194318 The re-evaluates the comment character when "amend" is toggled in the Git Staging view. Otherwise I see no problem with the "auto" setting. If the problem you reported was not related to amending a commit: please give concrete steps to reproduce. Are you using a commit message template? Not syntax-coloring is a very bad idea; if it's colored as comment, EGit will treat it as a comment and remove it. If we don't syntax-color comments, users will be left wondering why some lines were removed.
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/194318 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=01bd2a5535aa3ef60cafb3430a04fe8aadd4e6ba
This bug is related to bug 580213. I would both turn on filtering of comment lines in commit message and syntax highlighting for comment lines only if git has inserted comments into the commit message itself. I believe that this makes sense conceptually: Commit comments are a way for git to talk to the user. So if git does not need to talk to the user all logic concerning comments should be deactivated. Based on my tests, this is also how c-git handles comments. It never makes sense for users to write commit messages because no one can read them. This is in contrast to how comments are usually used: As a way of talking to a future developer (or your future self).
(In reply to Simon Sohrt from comment #5) > It never makes sense for users to write commit messages because no one can *comment messages
Well: see bug 580213. EGit behaves like C git when the commit message is entered in an editor. I can see the argument for EGit having different behavior if the commit message is initially empty and applying only commit.cleanup=whitespace in that case if the git config setting is strip or scissors. Might make sense since Egit does not, contrary to C git, pre-fill the editor with explanatory text. However, while this would allow committing with a message like "#123 foo", users then might run into surprises when they rebase or merge and get conflicts, or similar things. Also squashing might then treat such lines as comments. Unless you set core.commentChar to some other character (or to auto). Or you change commit.cleanup=whitespace and remove comment lines manually. So not much is gained; the problem is just postponed. My recommendation if you want/need such commit messages: set core.commentChar=; . (Don't use auto, it'd still choose # for initially empty messages.)
Thank you for your explanation and patience. After your changes I consider this bug resolved.
