@@ -1566,6 +1566,8 @@ static int git_default_core_config(const char *var, const char *value,
else if (!strcasecmp(value, "auto"))
auto_comment_line_char = 1;
else if (value[0] && !value[1]) {
+ if (value[0] == '\n')
+ return error(_("core.commentChar cannot be newline"));
comment_line_char = value[0];
auto_comment_line_char = 0;
} else
@@ -401,6 +401,11 @@ test_expect_success 'strip comments with changed comment char' '
test -z "$(echo "; comment" | git -c core.commentchar=";" stripspace -s)"
'
+test_expect_success 'newline as commentchar is forbidden' '
+ test_must_fail git -c core.commentChar="$LF" stripspace -s 2>err &&
+ grep "core.commentChar cannot be newline" err
+'
+
test_expect_success '-c with single line' '
printf "# foo\n" >expect &&
printf "foo" | git stripspace -c >actual &&
Since we usually look for a comment char while parsing line-oriented files, setting core.commentChar to a single newline can confuse our code quite a bit. For example, using it with "git commit" causes us to fail to recognize any of the template as comments, including it in the config message. Which kind of makes sense, since the template content is on its own line (so no line can "start" with a newline). In other spots I would not be surprised if you can create more mischief (e.g., violating loop assumptions) but I didn't dig into it. Since comment characters are a local preference, to some degree this is a case of "if it hurts, don't do it". But given that this would be a silly and pointless thing to do, and that it makes it harder to reason about code parsing comment lines, let's just forbid it. There are other cases that are perhaps questionable (e.g., setting the comment char to a single space), but they seem to behave reasonably (at least a simple "git commit" will correctly identify and strip the template lines). So I haven't worried about going on a hunt for every stupid thing a user might do to themselves, and just focused on the most confusing case. Signed-off-by: Jeff King <peff@peff.net> --- In the string version I suppose you could set it to "\nexec rm -rf /" if you really wanted to treat yourself to a fun "git rebase". Again, this is all local, but it's perhaps nice to know that core.commentChar is not a vector for arbitrary code execution. (That of course made me wonder if setting it to just "exec rm -rf / " would work, as the rest of the template line would be ignored by "rm"; but that is self-defeating as we'd recognize the line as a comment and remove it). config.c | 2 ++ t/t0030-stripspace.sh | 5 +++++ 2 files changed, 7 insertions(+)