git/builtin/commit.c, branch v2.45.4

Merge branch 'gt/add-u-commit-i-pathspec-check'

2024-04-15T21:11:43Z

"git add -u " and "git commit [-i] " did not diagnose a pathspec element that did not match any files in certain situations, unlike "git add " did. * gt/add-u-commit-i-pathspec-check: builtin/add: error out when passing untracked path with -u builtin/commit: error out when passing untracked path with -i revision: optionally record matches with pathspec elements

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

builtin/commit: error out when passing untracked path with -i

2024-04-03T21:55:22Z

When we provide a pathspec which does not match any tracked path alongside --include, we do not error like without --include. If there is something staged, it will commit the staged changes and ignore the pathspec which does not match any tracked path. And if nothing is staged, it will print the status. Exit code is 0 in both cases (unlike without --include). This is also described in the TODO comment before the relevant testcase. Fix this by passing a character array to add_files_to_cache() to collect the pathspec matching information and error out if the given path is untracked. Also, amend the testcase to check for the error message and remove the TODO comment. Signed-off-by: Ghanshyam Thakkar Signed-off-by: Junio C Hamano

revision: optionally record matches with pathspec elements

2024-04-03T21:55:21Z

Unlike "git add" and other end-user facing commands, where it is diagnosed as an error to give a pathspec with an element that does not match any path, the diff machinery does not care if some elements of the pathspec do not match. Given that the diff machinery is heavily used in pathspec-limited "git log" machinery, and it is common for a path to come and go while traversing the project history, this is usually a good thing. However, in some cases we would want to know if all the pathspec elements matched. For example, "git add -u " internally uses the machinery used by "git diff-files" to decide contents from what paths to add to the index, and as an end-user facing command, "git add -u" would want to report an unmatched pathspec element. Add a new .ps_matched member next to the .prune_data member in "struct rev_info" so that we can optionally keep track of the use of .prune_data pathspec elements that can be inspected by the caller. Signed-off-by: Junio C Hamano

Merge branch 'jc/show-untracked-false'

2024-03-28T21:13:50Z

The status.showUntrackedFiles configuration variable had a name that tempts users to set a Boolean value expressed in our usual "false", "off", and "0", but it only took "no". This has been corrected so "true" and its synonyms are taken as "normal", while "false" and its synonyms are taken as "no". * jc/show-untracked-false: status: allow --untracked=false and friends status: unify parsing of --untracked= and status.showUntrackedFiles

Merge branch 'eb/hash-transition'

2024-03-28T21:13:50Z

Work to support a repository that work with both SHA-1 and SHA-256 hash algorithms has started. * eb/hash-transition: (30 commits) t1016-compatObjectFormat: add tests to verify the conversion between objects t1006: test oid compatibility with cat-file t1006: rename sha1 to oid test-lib: compute the compatibility hash so tests may use it builtin/ls-tree: let the oid determine the output algorithm object-file: handle compat objects in check_object_signature tree-walk: init_tree_desc take an oid to get the hash algorithm builtin/cat-file: let the oid determine the output algorithm rev-parse: add an --output-object-format parameter repository: implement extensions.compatObjectFormat object-file: update object_info_extended to reencode objects object-file-convert: convert commits that embed signed tags object-file-convert: convert commit objects when writing object-file-convert: don't leak when converting tag objects object-file-convert: convert tag objects when writing object-file-convert: add a function to convert trees between algorithms object: factor out parse_mode out of fast-import and tree-walk into in object.h cache: add a function to read an OID of a specific algorithm tag: sign both hashes commit: export add_header_signature to support handling signatures on tags ...

status: allow --untracked=false and friends

2024-03-13T17:43:32Z

It is natural to expect that the "--untracked" option and the status.showuntrackedFiles configuration variable to take a Boolean value ("do you want me to show untracked files?"), but the current code takes nothing but "no" as "no, please do not show any". Allow the usual Boolean values to be given, and treat 'true' as "normal", and 'false' as "no". Signed-off-by: Junio C Hamano

status: unify parsing of --untracked= and status.showUntrackedFiles

2024-03-13T17:43:32Z

There are two code paths that take a string and parse it to enum untracked_status_type. Introduce a helper function and use it. As these two places handle an error differently, add an additional invalid value to the enum, and have the caller of the helper handle the error condition, instead of dying or emitting error message from the helper. Signed-off-by: Junio C Hamano

prefer comment_line_str to comment_line_char for printing

2024-03-12T20:28:10Z

As part of our transition to multi-byte comment characters, we should use the string variable rather than the historical character variable. All of the sites adjusted here are just swapping out "%c" for "%s" in format strings, or strbuf_addch() for strbuf_addstr(). The type system and printf-attribute give the compiler enough information to make sure our formats and variable changes all match (especially important for cases where the format string is defined far away from its use, like prepare_to_commit() in commit.c). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

strbuf: accept a comment string for strbuf_stripspace()

2024-03-12T20:28:10Z

As part of our transition to multi-byte comment characters, let's take a NUL-terminated string pointer for strbuf_stripspace(), rather than a single character. We can continue to support its feature of ignoring comments by accepting a NULL pointer (as opposed to the current behavior of a NUL byte). All of the callers have to be adjusted, but they can all just pass comment_line_str (or NULL). Inside the function we detect comments by comparing the first byte of a line to the comment character. We'll adjust that to use starts_with(), which will match multiple bytes (though for now, of course, we still only allow a single byte, so it's academic). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano