git/parse-options.c, branch v2.42.2

parse-options: disallow negating OPTION_SET_INT 0

2023-08-08T23:55:07Z

An option of type OPTION_SET_INT can be defined to set its variable to zero. It's negated variant will do the same, though, which is confusing. Several such options were fixed by disabling negation, changing the value to set or using a different option type: 991c552916 (ls-tree: fix --no-full-name, 2023-07-18) e12cb98e1e (branch: reject "--no-all" and "--no-remotes" early, 2023-07-18) 68cbb20e73 (show-branch: reject --[no-](topo|date)-order, 2023-07-19) 3821eb6c3d (reset: reject --no-(mixed|soft|hard|merge|keep) option, 2023-07-19) 36f76d2a25 (pack-objects: fix --no-quiet, 2023-07-21) 3a5f308741 (pack-objects: fix --no-keep-true-parents, 2023-07-21) c95ae3ff9c (describe: fix --no-exact-match, 2023-07-21) d089a06421 (bundle: use OPT_PASSTHRU_ARGV, 2023-07-29) Check for such options that allow negation in parse_options_check() and report them to find future cases quicker. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

short help: allow a gap smaller than USAGE_GAP

2023-07-19T23:39:02Z

The parse-options API responds to "git cmd -h" by listing the option flag (padded to the USAGE_OPTS_WIDTH column), followed by USAGE_GAP (set to 2) whitespaces, followed by the help text. If the flags part does not fit within the USAGE_OPTS_WIDTH, the help text is given on its own line. Imagine that "@" below depicts the USAGE_OPTS_WIDTH'th column, and "#" are for the usage help text, the output may look like this: @@@@@@@@@@@@@ ######################################## -f description of the flag '-f' comes here --short= description of the flag '--short' --very-long-option= description of the flag '--very-long-option' This is all good and nice in principle, but it becomes awkward when the flags part is just one column over the limit and forces a line break. See the description of the "--almost" option below: @@@@@@@@@@@@@ ######################################## -f description of the flag '-f' comes here --short= description of the flag '--short' --almost= description of the flag '--almost' --very-long-option= description of the flag '--very-long-option' If we allow shrinking the gap to a single whitespace only in such a case, we would instead get: @@@@@@@@@@@@@ ######################################## -f description of the flag '-f' comes here --short= description of the flag '--short' --almost= description of the flag '--almost' --very-long-option= description of the flag '--very-long-option' and the boundary between the flags and their descriptions does not become any harder to see, while saving precious vertical screen real estate. Signed-off-by: Junio C Hamano

short help: allow multi-line opthelp

2023-07-19T23:30:06Z

When "-h" triggers the short-help in a command that implements its option parsing using the parse-options API, the option help text is shown with a single fprintf() as a long line. When the text is multi-line, the second and subsequent lines are not left padded, that breaks the alignment across options. Borrowing the idea from the advice API where its hint strings are shown with (localized) "hint:" prefix, let's internally split the (localized) help text into lines, and showing the first line, pad the remaining lines to align. Signed-off-by: Junio C Hamano

commit.h: reduce unnecessary includes

2023-04-24T19:47:33Z

Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

treewide: remove unnecessary includes of cache.h

2023-03-21T17:56:53Z

The last several commits were geared at replacing the include of cache.h in strbuf.c with an include of git-compat-util.h. Unfortunately, I had to drop a patch moving some functions from cache.h to object-name.h, due to excessive conflicts with other in-flight topics. However, even without that patch, the series of patches so far allows us to modify a number of C files to replace an include of cache.h with git-compat-util.h. Do that to reduce our dependencies. (If we could have kept our object-name.h patch in this series, it would have also let us reduce the includes in checkout.c and fmt-merge-msg.c in addition to strbuf.c). Just to ensure that nothing else was bringing in cache.h, all of the affected files have been checked to ensure that gcc -E -I. $SOURCE_FILE | grep '"cache.h"' found no hits and that make DEVELOPER=1 ${OBJECT_FILE_FOR_SOURCE_FILE} successfully compiles without warnings. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

abspath.h: move absolute path functions from cache.h

2023-03-21T17:56:52Z

This is another step towards letting us remove the include of cache.h in strbuf.c. It does mean that we also need to add includes of abspath.h in a number of C files. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

treewide: be explicit about dependence on gettext.h

2023-03-21T17:56:51Z

Dozens of files made use of gettext functions, without explicitly including gettext.h. This made it more difficult to find which files could remove a dependence on cache.h. Make C files explicitly include gettext.h if they are using it. However, while compat/fsmonitor/fsm-ipc-darwin.c should also gain an include of gettext.h, it was left out to avoid conflicting with an in-flight topic. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'jk/bundle-use-dash-for-stdfiles'

2023-03-19T22:03:12Z

"git bundle" learned that "-" is a common way to say that the input comes from the standard input and/or the output goes to the standard output. It used to work only for output and only from the root level of the working tree. * jk/bundle-use-dash-for-stdfiles: parse-options: use prefix_filename_except_for_dash() helper parse-options: consistently allocate memory in fix_filename() bundle: don't blindly apply prefix_filename() to "-" bundle: document handling of "-" as stdin bundle: let "-" mean stdin for reading operations

parse-options: use prefix_filename_except_for_dash() helper

2023-03-06T21:14:53Z

Since our fix_filename()'s only remaining special case is handling "-", we can use the newly-minted helper function that handles this already. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

parse-options: consistently allocate memory in fix_filename()

2023-03-06T21:14:45Z

When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in front of the filename to make up for the fact that Git has chdir()'d to the top of the repository. We can do this with prefix_filename(), but there are a few special cases we handle ourselves. Unfortunately the memory allocation is inconsistent here; if we do make it to prefix_filename(), we'll allocate a string which the caller must free to avoid a leak. But if we hit our special cases, we'll return the string as-is, and a caller which tries to free it will crash. So there's no way to win. Let's consistently allocate, so that callers can do the right thing. There are now three cases to care about in the function (and hence a three-armed if/else): 1. we got a NULL input (and should leave it as NULL, though arguably this is the sign of a bug; let's keep the status quo for now and we can pick at that scab later) 2. we hit a special case that means we leave the name intact; we should duplicate the string. This includes our special "-" matching. Prior to this patch, it also included empty prefixes and absolute filenames. But we can observe that prefix_filename() already handles these, so we don't need to detect them. 3. everything else goes to prefix_filename() I've dropped the "const" from the "char **file" parameter to indicate that we're allocating, though in practice it's not really important. This is all being shuffled through a void pointer via opt->value before it hits code which ever looks at the string. And it's even a bit weird, because we are really taking _in_ a const string and using the same out-parameter for a non-const string. A better function signature would be: static char *fix_filename(const char *prefix, const char *file); but that would mean the caller dereferences the double-pointer (and the NULL check is currently handled inside this function). So I took the path of least-change here. Note that we have to fix several callers in this commit, too, or we'll break the leak-checking tests. These are "new" leaks in the sense that they are now triggered by the test suite, but these spots have always been leaky when Git is run in a subdirectory of the repository. I fixed all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There may be others in scripts that have other leaks, but we can fix them later along with those other leaks (and again, you _couldn't_ fix them before this patch, so this is the necessary first step). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano