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

add-patch: plug a leak handling the '/' command

2024-04-22T23:27:42Z

Plug a leak we have since d6cf873340 (built-in add -p: implement the '/' ("search regex") command, 2019-12-13). This leak can be triggered with: $ printf "A\n\nB\n" >file $ git add file && git commit -m file $ printf "AA\n\nBB\n" >file $ printf "s\n/ .\n" >lines $ git add -p Signed-off-by: Junio C Hamano

Merge branch 'rj/add-p-explicit-reshow'

2024-04-09T21:31:44Z

"git add -p" and other "interactive hunk selection" UI has learned to skip showing the hunk immediately after it has already been shown, and an additional action to explicitly ask to reshow the current hunk. * rj/add-p-explicit-reshow: add-patch: do not print hunks repeatedly add-patch: introduce 'p' in interactive-patch

add-patch: do not print hunks repeatedly

2024-03-29T17:12:39Z

The interactive-patch is a sequential process where, on each step, we print one hunk from a patch and then ask the user how to proceed. There is a possibility of repeating a step, for example if the user enters a non-applicable option, i.e: "s" $ git add -p diff --git a/add-patch.c b/add-patch.c index 52be1ddb15..8fb75e82e2 100644 --- a/add-patch.c +++ b/add-patch.c @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n" static int patch_update_file(struct add_p_state *s, struct file_diff *file_diff) { - size_t hunk_index = 0; + size_t hunk_index = 0, prev_hunk_index = -1; ssize_t i, undecided_previous, undecided_next; struct hunk *hunk; char ch; (1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? s Sorry, cannot split this hunk @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n" static int patch_update_file(struct add_p_state *s, struct file_diff *file_diff) { - size_t hunk_index = 0; + size_t hunk_index = 0, prev_hunk_index = -1; ssize_t i, undecided_previous, undecided_next; struct hunk *hunk; char ch; (1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? ... or an invalid option, i.e: "U" $ git add -p diff --git a/add-patch.c b/add-patch.c index 52be1ddb15..8fb75e82e2 100644 --- a/add-patch.c +++ b/add-patch.c @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n" static int patch_update_file(struct add_p_state *s, struct file_diff *file_diff) { - size_t hunk_index = 0; + size_t hunk_index = 0, prev_hunk_index = -1; ssize_t i, undecided_previous, undecided_next; struct hunk *hunk; char ch; (1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? U y - stage this hunk n - do not stage this hunk q - quit; do not stage this hunk or any of the remaining ones a - stage this hunk and all later hunks in the file d - do not stage this hunk or any of the later hunks in the file j - leave this hunk undecided, see next undecided hunk J - leave this hunk undecided, see next hunk g - select a hunk to go to / - search for a hunk matching the given regex e - manually edit the current hunk p - print again the current hunk ? - print help @@ -1394,7 +1394,7 @@ N_("j - leave this hunk undecided, see next undecided hunk\n" static int patch_update_file(struct add_p_state *s, struct file_diff *file_diff) { - size_t hunk_index = 0; + size_t hunk_index = 0, prev_hunk_index = -1; ssize_t i, undecided_previous, undecided_next; struct hunk *hunk; char ch; (1/4) Stage this hunk [y,n,q,a,d,j,J,g,/,e,p,?]? Printing the chunk again followed by the question can be confusing as the user has to pay special attention to notice that the same chunk is being reconsidered. It can also be problematic if the chunk is longer than one screen height because the result of the previous iteration is lost off the screen (the help guide in the previous example). To avoid such problems, stop printing the chunk if the iteration does not advance to a different chunk. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

add-patch: introduce 'p' in interactive-patch

2024-03-29T05:40:08Z

Shortly we're going make interactive-patch stop printing automatically the hunk under certain circumstances. Let's introduce a new option to allow the user to explicitly request the printing. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

find multi-byte comment chars in NUL-terminated strings

2024-03-12T20:28:10Z

Several parts of the code need to identify lines that begin with the comment character, and do so with a simple byte equality check. As part of the transition to handling multi-byte characters, we need to match all of the bytes. For cases where we are looking in a NUL-terminated string, we can just use starts_with(), which checks all of the characters in comment_line_str. Note that we can drop the "line.len" check in wt-status.c's read_rebase_todolist(). The starts_with() function handles the case of an empty haystack buffer (it will always return false for a non-empty prefix). Signed-off-by: Jeff King 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_commented_addf()

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_commented_addf() rather than a single character. All of the callers have to be adjusted, but they can just pass comment_line_str rather than comment_line_char. Note that we rely on strbuf_add_commented_lines() under the hood, so we'll cheat a bit to squeeze our string into a single character (for now the two are equivalent, and we'll address this TODO in the next patch). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add-patch: classify '@' as a synonym for 'HEAD'

2024-02-13T22:12:51Z

Currently, (restore, checkout, reset) commands correctly take '@' as a synonym for 'HEAD'. However, in patch mode different prompts/messages are given on command line due to patch mode machinery not considering '@' to be a synonym for 'HEAD' due to literal string comparison with the word 'HEAD', and therefore assigning patch_mode_($command)_nothead and triggering reverse mode (-R in diff-index). The NEEDSWORK comment suggested comparing commit objects to get around this. However, doing so would also take a non-checked out branch pointing to the same commit as HEAD, as HEAD. This would cause confusion to the user. Therefore, after parsing '@', replace it with 'HEAD' as reasonably early as possible. This also solves another problem of disparity between 'git checkout HEAD' and 'git checkout @' (latter detaches at the HEAD commit and the former does not). Trade-offs: - Some of the errors would show the revision argument as 'HEAD' when given '@'. This should be fine, as most users who probably use '@' would be aware that it is a shortcut for 'HEAD' and most probably used to use 'HEAD'. There is also relevant documentation in 'gitrevisions' manpage about '@' being the shortcut for 'HEAD'. Also, the simplicity of the solution far outweighs this cost. - Consider '@' as a shortcut for 'HEAD' even if 'refs/heads/@' exists at a different commit. Naming a branch '@' is an obvious foot-gun and many existing commands already take '@' for 'HEAD' even if 'refs/heads/@' exists at a different commit or does not exist at all (e.g. 'git log @', 'git push origin @' etc.). Therefore this is an existing assumption and should not be a problem. Helped-by: Junio C Hamano Helped-by: Phillip Wood Signed-off-by: Ghanshyam Thakkar Signed-off-by: Junio C Hamano

treewide: remove unnecessary includes in source files

2023-12-26T20:04:31Z

Each of these were checked with gcc -E -I. ${SOURCE_FILE} | grep ${HEADER_FILE} to ensure that removing the direct inclusion of the header actually resulted in that header no longer being included at all (i.e. that no other header pulled it in transitively). ...except for a few cases where we verified that although the header was brought in transitively, nothing from it was directly used in that source file. These cases were: * builtin/credential-cache.c * builtin/pull.c * builtin/send-pack.c Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'cw/compat-util-header-cleanup'

2023-07-17T18:30:42Z

Further shuffling of declarations across header files to streamline file dependencies. * cw/compat-util-header-cleanup: git-compat-util: move alloc macros to git-compat-util.h treewide: remove unnecessary includes for wrapper.h kwset: move translation table from ctype sane-ctype.h: create header for sane-ctype macros git-compat-util: move wrapper.c funcs to its header git-compat-util: move strbuf.c funcs to its header