git/add-patch.c, branch v2.46.2

Merge branch 'pw/add-patch-with-suppress-blank-empty' into maint-2.46

2024-08-16T19:50:54Z

"git add -p" by users with diff.suppressBlankEmpty set to true failed to parse the patch that represents an unmodified empty line with an empty line (not a line with a single space on it), which has been corrected. * pw/add-patch-with-suppress-blank-empty: add-patch: use normalize_marker() when recounting edited hunk add-patch: handle splitting hunks with diff.suppressBlankEmpty

add-patch: use normalize_marker() when recounting edited hunk

2024-07-20T23:29:15Z

After the user has edited a hunk the number of lines in the pre- and post- image lines is recounted the hunk header can be updated before passing the hunk to "git apply". The recounting code correctly handles empty context lines where the leading ' ' is omitted by treating '\n' and '\r' as context lines. Update this code to use normalize_marker() so that the handling of empty context lines is consistent with the rest of the hunk parsing code. There is a small change in behavior as normalize_marker() only treats "\r\n" as an empty context line rather than any line starting with '\r'. This should not matter in practice as Macs have used Unix line endings since MacOs 10 was released in 2001 and if it transpires that someone is still using an earlier version of MacOs where lines end with '\r' then we will need to change the handling of '\r' in normalize_marker() anyway. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

add-patch: handle splitting hunks with diff.suppressBlankEmpty

2024-07-20T23:29:14Z

When "add -p" parses diffs, it looks for context lines starting with a single space. But when diff.suppressBlankEmpty is in effect, an empty context line will omit the space, giving us a true empty line. This confuses the parser, which is unable to split based on such a line. It's tempting to say that we should just make sure that we generate a diff without that option. However, although we do not parse hunks that the user has manually edited with parse_diff() we do allow the user to split such hunks. As POSIX calls the decision of whether to print the space here "implementation-defined" we need to handle edited hunks where empty context lines omit the space. So let's handle both cases: a context line either starts with a space or consists of a totally empty line by normalizing the first character to a space when we parse them. Normalizing the first character rather than changing the code to check for a space or newline will hopefully future proof against introducing similar bugs if the code is changed. Reported-by: Ilya Tumaykin Helped-by: Jeff King Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

Merge branch 'ps/use-the-repository'

2024-07-02T16:59:00Z

A CPP macro USE_THE_REPOSITORY_VARIABLE is introduced to help transition the codebase to rely less on the availability of the singleton the_repository instance. * ps/use-the-repository: hex: guard declarations with `USE_THE_REPOSITORY_VARIABLE` t/helper: remove dependency on `the_repository` in "proc-receive" t/helper: fix segfault in "oid-array" command without repository t/helper: use correct object hash in partial-clone helper compat/fsmonitor: fix socket path in networked SHA256 repos replace-object: use hash algorithm from passed-in repository protocol-caps: use hash algorithm from passed-in repository oidset: pass hash algorithm when parsing file http-fetch: don't crash when parsing packfile without a repo hash-ll: merge with "hash.h" refs: avoid include cycle with "repository.h" global: introduce `USE_THE_REPOSITORY_VARIABLE` macro hash: require hash algorithm in `empty_tree_oid_hex()` hash: require hash algorithm in `is_empty_{blob,tree}_oid()` hash: make `is_null_oid()` independent of `the_repository` hash: convert `oidcmp()` and `oideq()` to compare whole hash global: ensure that object IDs are always padded hash: require hash algorithm in `oidread()` and `oidclr()` hash: require hash algorithm in `hasheq()`, `hashcmp()` and `hashclr()` hash: drop (mostly) unused `is_empty_{blob,tree}_sha1()` functions

Merge branch 'jc/varargs-attributes'

2024-06-17T22:55:55Z

Varargs functions that are unannotated as printf-like or execl-like have been annotated as such. * jc/varargs-attributes: __attribute__: add a few missing format attributes __attribute__: mark some functions with LAST_ARG_MUST_BE_NULL __attribute__: remove redundant attribute declaration for git_die_config() __attribute__: trace2_region_enter_printf() is like "printf"

global: introduce `USE_THE_REPOSITORY_VARIABLE` macro

2024-06-14T17:26:33Z

Use of the `the_repository` variable is deprecated nowadays, and we slowly but steadily convert the codebase to not use it anymore. Instead, callers should be passing down the repository to work on via parameters. It is hard though to prove that a given code unit does not use this variable anymore. The most trivial case, merely demonstrating that there is no direct use of `the_repository`, is already a bit of a pain during code reviews as the reviewer needs to manually verify claims made by the patch author. The bigger problem though is that we have many interfaces that implicitly rely on `the_repository`. Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code units to opt into usage of `the_repository`. The intent of this macro is to demonstrate that a certain code unit does not use this variable anymore, and to keep it from new dependencies on it in future changes, be it explicit or implicit For now, the macro only guards `the_repository` itself as well as `the_hash_algo`. There are many more known interfaces where we have an implicit dependency on `the_repository`, but those are not guarded at the current point in time. Over time though, we should start to add guards as required (or even better, just remove them). Define the macro as required in our code units. As expected, most of our code still relies on the global variable. Nearly all of our builtins rely on the variable as there is no way yet to pass `the_repository` to their entry point. For now, declare the macro in "biultin.h" to keep the required changes at least a little bit more contained. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

hash: require hash algorithm in `empty_tree_oid_hex()`

2024-06-14T17:26:33Z

The `empty_tree_oid_hex()` function use `the_repository` to derive the hash function that shall be used. Require callers to pass in the hash algorithm to get rid of this implicit dependency. While at it, remove the unused `empty_blob_oid_hex()` function. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

attribute: mark some functions with LAST_ARG_MUST_BE_NULL

2024-06-10T16:16:30Z

Some varargs functions that use NULL-terminated parameter list were missing __attributes__ ((sentinel)) aka LAST_ARG_MUST_BE_NULL. Add them. Signed-off-by: Junio C Hamano

add-patch: enforce only one-letter response to prompts

2024-05-22T21:46:31Z

In a "git add -p" session, especially when we are not using the single-key mode, we may see 'qa' as a response to a prompt (1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? and then just do the 'q' thing (i.e. quit the session), ignoring everything other than the first byte. If 'q' and 'a' are next to each other on the user's keyboard, there is a plausible chance that we see 'qa' when the user who wanted to say 'a' fat-fingered and we ended up doing the 'q' thing instead. As we didn't think of a good reason during the review discussion why we want to accept excess letters only to ignore them, it appears to be a safe change to simply reject input that is longer than just one byte. The two exceptions are the 'g' command that takes a hunk number, and the '/' command that takes a regular expression. They have to be accompanied by their operands (this makes me wonder how users who set the interactive.singlekey configuration feed these operands---it turns out that we notice there is no operand and give them another chance to type the operand separately, without using single key input this time), so we accept a string that is more than one byte long. Keep the "use only the first byte, downcased" behaviour when we ask yes/no question, though. Neither on Qwerty or on Dvorak, 'y' and 'n' are not close to each other. Signed-off-by: Junio C Hamano

Merge branch 'rj/add-p-typo-reaction'

2024-05-08T17:18:45Z

When the user responds to a prompt given by "git add -p" with an unsupported command, list of available commands were given, which was too much if the user knew what they wanted to type but merely made a typo. Now the user gets a much shorter error message. * rj/add-p-typo-reaction: add-patch: response to unknown command add-patch: do not show UI messages on stderr