git/config.c, branch v2.45.0

Merge branch 'jc/unleak-core-excludesfile'

2024-04-15T21:11:44Z

The variable that holds the value read from the core.excludefile configuration variable used to leak, which has been corrected. * jc/unleak-core-excludesfile: config: do not leak excludes_file

config: do not leak excludes_file

2024-04-08T20:20:24Z

The excludes_file variable is marked "const char *", but all the assignments to it are made with a piece of memory allocated just for it, and the variable is responsible for owning it. When "core.excludesfile" is read, the code just lost the previous value, leaking memory. Plug it. The real problem is that the variable is mistyped; our convention is to never make a variable that owns the piece of memory pointed by it as "const". Fixing that would reduce the chance of this kind of bug happening, and also would make it unnecessary to cast the constness away while free()ing it, but that would be a much larger follow-up effort. Reported-by: Rubén Justo Signed-off-by: Junio C Hamano

Merge branch 'jk/core-comment-string'

2024-04-05T17:49:49Z

core.commentChar used to be limited to a single byte, but has been updated to allow an arbitrary multi-byte sequence. * jk/core-comment-string: config: add core.commentString config: allow multi-byte core.commentChar environment: drop comment_line_char compatibility macro wt-status: drop custom comment-char stringification sequencer: handle multi-byte comment characters when writing todo list find multi-byte comment chars in unterminated buffers find multi-byte comment chars in NUL-terminated strings prefer comment_line_str to comment_line_char for printing strbuf: accept a comment string for strbuf_add_commented_lines() strbuf: accept a comment string for strbuf_commented_addf() strbuf: accept a comment string for strbuf_stripspace() environment: store comment_line_char as a string strbuf: avoid shadowing global comment_line_char name commit: refactor base-case of adjust_comment_line_char() strbuf: avoid static variables in strbuf_add_commented_lines() strbuf: simplify comment-handling in add_lines() helper config: forbid newline as core.commentChar

Merge branch 'rs/config-comment'

2024-04-05T17:49:49Z

"git config" learned "--comment=" option to leave a comment immediately after the "variable = value" on the same line in the configuration file. * rs/config-comment: config: allow tweaking whitespace between value and comment config: fix --comment formatting config: add --comment option to add a comment

Merge branch 'ds/config-internal-whitespace-fix'

2024-04-01T20:21:34Z

"git config" corrupted literal HT characters written in the configuration file as part of a value, which has been corrected. * ds/config-internal-whitespace-fix: config.txt: describe handling of whitespace further t1300: add more tests for whitespace and inline comments config: really keep value-internal whitespace verbatim config: minor addition of whitespace

config: add core.commentString

2024-03-27T15:48:54Z

The core.commentChar code recently learned to accept more than a single ASCII character. But using it is annoying with multiple versions of Git, since older ones will reject it outright: $ git.v2.44.0 -c core.commentchar=foo stripspace -s error: core.commentChar should only be one ASCII character fatal: unable to parse 'core.commentchar' from command-line config Let's add an alias core.commentString. That's arguably a better name anyway, since we now can handle strings, and it makes it possible to have a config that works reasonably with both old and new versions of Git (see the example in the documentation). This is strictly an alias, so there's not much point in adding duplicate tests; I added a single one to t0030 that exercises the alias code. Note also that the error messages for invalid values will now show the variable the config parser handed us, and thus will be normalized to lowercase (rather than camelcase). A few tests in t0030 are adjusted to match. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

config: really keep value-internal whitespace verbatim

2024-03-21T22:57:09Z

Fix a bug in function parse_value() that prevented whitespace characters (i.e. spaces and horizontal tabs) found inside configuration option values from being parsed and returned in their original form. The bug caused any number of consecutive whitespace characters to be wrongly "squashed" into the same number of space characters. This bug was introduced back in July 2009, in commit ebdaae372b46 ("config: Keep inner whitespace verbatim"). Further investigation showed that setting a configuration value, by invoking git-config(1), converts value-internal horizontal tabs into "\t" escape sequences, which the buggy value-parsing logic in function parse_value() didn't "squash" into spaces. That's why the test included in the ebdaae37 commit passed, which presumably made the bug remain undetected for this long. On the other hand, value-internal literal horizontal tab characters, found in a configuration file edited by hand, do get "squashed" by the value-parsing logic, so the right choice was to fix this bug by making the value-internal whitespace characters preserved verbatim. Signed-off-by: Dragan Simic Signed-off-by: Junio C Hamano

config: minor addition of whitespace

2024-03-21T22:57:09Z

In general, binary operators should be enclosed in a pair of leading and trailing space (SP) characters. Thus, clean up one spotted expression that for some reason had a "bunched up" operator. Signed-off-by: Dragan Simic Signed-off-by: Junio C Hamano

config: allow tweaking whitespace between value and comment

2024-03-15T23:07:39Z

Extending the previous step, this allows the whitespace placed after the value before the "# comment message" to be tweaked by tweaking the preprocessing rule to: * If the given comment string begins with one or more whitespace characters followed by '#', it is passed intact. * If the given comment string begins with '#', a Space is prepended. * Otherwise, " # " (Space, '#', Space) is prefixed. * A string with LF in it cannot be used as a comment string. Unlike the previous step, which unconditionally added a space after the value before writing the "# comment string", because the above preprocessing already gives a whitespace before the '#', the resulting string is written immediately after copying the value. And the sanity checking rule becomes * comment string after the above massaging that comes into git_config_set_multivar_in_file_gently() must - begin with zero or more whitespace characters followed by '#'. - not have a LF in it. I personally think this is over-engineered, but since I thought things through anyway, here it is in the patch form. The logic to tweak end-user supplied comment string is encapsulated in a new helper function, git_config_prepare_comment_string(), so if new front-end callers would want to use the same massaging rules, it is easily reused. Unfortunately I do not think of a way to tweak the preprocessing rules further to optionally allow having no blank after the value, i.e. to produce [section] variable = value#comment (which is a valid way to say section.variable=value, by the way) without sacrificing the ergonomics for the more usual case, so this time I really stop here. Signed-off-by: Junio C Hamano

config: fix --comment formatting

2024-03-15T23:07:37Z

When git adds comments itself (like "rebase -i" todo list and "commit -e" log message editor), it always gives a comment introducer "#" followed by a Space before the message, except for the recently introduced "git config --comment", where the users are forced to say " this is my comment" if they want to add their comment in this usual format; otherwise their comment string will end up without a space after the "#". Make it more ergonomic, while keeping it possible to also use this unusual style, by massaging the comment string at the UI layer with a set of simple rules: * If the given comment string begins with '#', it is passed intact. * Otherwise, "# " is prefixed. * A string with LF in it cannot be used as a comment string. Right now there is only one "front-end" that accepts end-user comment string and calls the underlying machinery to add or modify configuration file with comments, but to make sure that the future callers perform similar massaging as they see fit, add a sanity check logic in git_config_set_multivar_in_file_gently(), which is the single choke point in the codepaths that consumes the comment string. Signed-off-by: Junio C Hamano