Re: [PATCH v2] Allow custom "comment char"

Ralf Thielow [off-list ref] writes:

From: Junio C Hamano <redacted>

Some users do want to write a line that begin with a pound sign, #,
in their commit log message.  Many tracking system recognise
a token of #<bugid> form, for example.

The support we offer these use cases is not very friendly to the end
users.  They have a choice between

 - Don't do it.  Avoid such a line by rewrapping or indenting; and

 - Use --cleanup=whitespace but remove all the hint lines we add.

Give them a way to set a custom comment char, e.g.

    $ git -c core.commentchar="%" commit

so that they do not have to do either of the two workarounds.

Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Ralf Thielow <redacted>
---
Junio, thanks for the code in your reply to the
first version. It works very well and looks nice.
I was also unhappy about this "\n%c\n" thing and
pretty unsure with the code in "git-submodule.sh".
But with this, it looks good to me. Thanks.

Changes in v2:
- extend "git stripspace" with an option to make
  it's input being converted to commented lines
- teach git-submodule.sh using this
- rename strbuf_commented_addstr to strbuf_add_commented_lines
  and improve it's design

Oh, I love it when something like this happens.  Throw a "perhaps
along these lines" patch and then a finished product that fills the
gaps I didn't bother to fill magically appears, even with tests and
updates to comments and documentation.

What good things did I do recently to deserve such a luck? ;-)

This leaks msg (inherited from my "perhaps along these lines"
patch).  I think I can just add free(msg) at the end.

+	if (strip_comments || mode == COMMENT_LINES)
+		git_config(git_default_config, NULL);

Nice spotting.  The "along these lines" patch broke "stripspace -s"
under custom comment line char; this fixes it.

Thanks.