git/builtin/patch-id.c, branch v2.48.2

builtin/patch-id: fix type of `get_one_patchid()`

2024-12-06T11:20:05Z

In `get_one_patchid()` we assign either the result of `strlen()` or `remove_space()` to `len`. But while the former correctly returns a `size_t`, the latter returns an `int` to indicate the length of the stripped string even though it cannot ever return a negative value. This causes a warning with "-Wsign-conversion". In fact, even `get_one_patchid()` itself is also using an integer as return value even though it always returns the length of the patch, and this bubbles up to other callers. Adapt the function and its helpers to use `size_t` for string lengths consistently. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

global: mark code units that generate warnings with `-Wsign-compare`

2024-12-06T11:20:02Z

Mark code units that generate warnings with `-Wsign-compare`. This allows for a structured approach to get rid of all such warnings over time in a way that can be easily measured. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'jc/pass-repo-to-builtins'

2024-09-23T17:35:09Z

The convention to calling into built-in command implementation has been updated to pass the repository, if known, together with the prefix value. * jc/pass-repo-to-builtins: add: pass in repo variable instead of global the_repository builtin: remove USE_THE_REPOSITORY for those without the_repository builtin: remove USE_THE_REPOSITORY_VARIABLE from builtin.h builtin: add a repository parameter for builtin functions

Revert "Merge branch 'jc/patch-id' into maint-2.46"

2024-09-16T22:12:06Z

This reverts commit 41c952ebacf7e3369e7bee721f768114d65e50c4, reversing changes made to 712d970c0145b95ce655773e7cd1676f09dfd215. Keeping a known breakage for now is better than introducing new regression(s).

builtin: remove USE_THE_REPOSITORY_VARIABLE from builtin.h

2024-09-13T21:32:24Z

Instead of including USE_THE_REPOSITORY_VARIABLE by default on every builtin, remove it from builtin.h and add it to all the builtins that include builtin.h (by definition, that means all builtins/*.c). Also, remove the include statement for repository.h since it gets brought in through builtin.h. The next step will be to migrate each builtin from having to use the_repository. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

builtin: add a repository parameter for builtin functions

2024-09-13T21:27:08Z

In order to reduce the usage of the global the_repository, add a parameter to builtin functions that will get passed a repository variable. This commit uses UNUSED on most of the builtin functions, as subsequent commits will modify the actual builtins to pass the repository parameter down. Signed-off-by: John Cai Signed-off-by: Junio C Hamano

Merge branch 'jc/patch-id' into maint-2.46

2024-09-12T18:02:16Z

The patch parser in "git patch-id" has been tightened to avoid getting confused by lines that look like a patch header in the log message. cf. * jc/patch-id: patch-id: tighten code to detect the patch header patch-id: rewrite code that detects the beginning of a patch patch-id: make get_one_patchid() more extensible patch-id: call flush_current_id() only when needed t4204: patch-id supports various input format

Merge branch 'jc/patch-id'

2024-08-14T21:54:53Z

The patch parser in "git patch-id" has been tightened to avoid getting confused by lines that look like a patch header in the log message. * jc/patch-id: patch-id: tighten code to detect the patch header patch-id: rewrite code that detects the beginning of a patch patch-id: make get_one_patchid() more extensible patch-id: call flush_current_id() only when needed t4204: patch-id supports various input format

patch-id: tighten code to detect the patch header

2024-07-30T01:19:14Z

The get_one_patchid() function unconditionally takes a line that matches the patch header (namely, a line that begins with a full object name, possibly prefixed by "commit" or "From" plus a space) as the beginning of a patch. Even when it is *not* looking for one (namely, when the previous call found the patch header and returned, and then we are called again to skip the log message and process the patch whose header was found by the previous invocation). As a consequence, a line in the commit log message that begins with one of these patterns can be mistaken to start another patch, with current message entirely skipped (because we haven't even reached the patch at all). Allow the caller to tell us if it called us already and saw the patch header (in which case we shouldn't be looking for another one, until we see the "diff" part of the patch; instead we simply should be skipping these lines as part of the commit log message), and skip the header processing logic when that is the case. In the helper function, it also needs to flip this "are we looking for a header?" bit, once it finished skipping the commit log message and started processing the patches, as the patch header of the _next_ message is the only clue in the input that the current patch is done. Signed-off-by: Junio C Hamano

patch-id: rewrite code that detects the beginning of a patch

2024-07-30T01:19:14Z

The get_one_patchid() function reads input lines until it finds a patch header (the line that begins a patch), whose beginning is one of: (1) an "", which is what "git diff-tree --stdin" shows; (2) "commit ", which is what "git log" shows; or (3) "From ", which is what "git log --format=email" shows. When it finds such a line, it returns to the caller, reporting the it found, and the size of the "patch" it processed. The caller then calls the function again, which then ignores the commit log message, and then processes the lines in the patch part until it hits another "beginning of a patch". The above logic was fairly easy to see until 2bb73ae8 (patch-id: use starts_with() and skip_prefix(), 2016-05-28) reorganized the code, which made another logic that has nothing to do with the "where does the next patch begin?" logic, which came from 2485eab5 (git-patch-id: do not trip over "no newline" markers, 2011-02-17) that ignores the "\ No newline at the end", rolled into the same single if() statement. Let's split it out. The "\ No newline at the end" marker is part of the patch, should not appear before we start reading the patch part, and does not belong to the detection of patch header. Signed-off-by: Junio C Hamano