user/sven/git.git/add-patch.c, branch origin/maint

add-patch: quit on EOF

2025-10-26T23:34:39Z

If we reach the end of the input, e.g. because the user pressed ctrl-D on Linux, there is no point in showing any more prompts, as we won't get any reply. Do the same as option 'q' would: Quit. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: quit without skipping undecided hunks

2025-10-25T16:45:07Z

Option q implies d, i.e., it marks any undecided hunks towards the bottom of the hunk array as skipped. This is unnecessary; later code treats undecided and skipped hunks the same: The only functions that use UNDECIDED_HUNK and SKIP_HUNK are patch_update_file() itself (but not after its big for loop) and its helpers get_first_undecided() and display_hunks(). Streamline the handling of option q by quitting immediately. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'rs/add-patch-document-p-for-pager'

2025-10-24T20:48:05Z

Show 'P'ipe command in "git add -p". * rs/add-patch-document-p-for-pager: add-patch: fully document option P

add-patch: fully document option P

2025-10-21T21:35:44Z

Show option P in the prompt and explain it properly on a dedicated line in online help and documentation. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'rs/add-patch-options-fix'

2025-10-17T21:02:17Z

The code in "git add -p" and friends to iterate over hunks was riddled with bugs, which has been corrected. * rs/add-patch-options-fix: add-patch: reset "permitted" at loop start add-patch: let options a and d roll over like y and n add-patch: let options k and K roll over like j and J add-patch: let options y, n, j, and e roll over to next undecided add-patch: document that option J rolls over add-patch: improve help for options j, J, k, and K

Merge branch 'pw/add-p-hunk-splitting-fix'

2025-10-14T19:56:09Z

Marking a hunk 'selected' in "git add -p" and then splitting made all the split pieces 'selected'; this has been changed to make them all 'undecided', which gives better end-user experience. * pw/add-p-hunk-splitting-fix: add-patch: update hunk splitability after editing add -p: mark split hunks as undecided

add-patch: reset "permitted" at loop start

2025-10-06T17:51:43Z

Don't accumulate allowed options from any visited hunks, start fresh at the top of the loop instead and only record the allowed options for the current hunk. Reported-by: Junio C Hamano Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: let options a and d roll over like y and n

2025-10-06T17:51:43Z

Options a and d stage and unstage all undecided hunks towards the bottom of the array of hunks, respectively, and then roll over to the very first hunk. The first part is similar to y and n if the current hunk is the last one in the array, but they roll over to the next undecided hunk if there is any. That's more useful; do it for a and d as well. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: let options k and K roll over like j and J

2025-10-06T17:51:42Z

Options j and J roll over at the bottom and go to the first undecided hunk and hunk 1, respectively. Let options k and K do the same when they reach the top of the hunk array, so let them go to the last undecided hunk and the last hunk, respectively, for consistency. Also use the same direction-neutral error messages. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

add-patch: let options y, n, j, and e roll over to next undecided

2025-10-06T17:51:42Z

The options y, n, and e mark the current hunk as decided. If there's another undecided hunk towards the bottom of the hunk array they go there. If there isn't, but there is another undecided hunk towards the top then they go to the very first hunk, no matter if it has already been decided on. The option j does basically the same move. Technically it is not allowed if there's no undecided hunk towards the bottom, but the variable "permitted" is never reset, so this permission is retained from the very first hunk. That may a bug, but this behavior is at least consistent with y, n, and e and arguably more useful than refusing to move. Improve the roll-over behavior of these four options by moving to the first undecided hunk instead of hunk 1, consistent with what they do when not rolling over. Also adjust the error message for j, as it will only be shown if there's no other undecided hunk in either direction. Reported-by: Windl, Ulrich Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano