On 25/02/21 02:57PM, Phillip Wood via GitGitGadget wrote:
> From: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
>
> When a hunk is split each of the new hunks inherits whether it is
> selected or not from the original hunk. This means that if a selected
> hunk is split all of the new hunks are selected and the user is not asked
> whether or not they want to select the new hunks. This is unfortunate as
> the user is presumably splitting the original hunk because they only
> want to select some sub-set of it. Fix this by marking all the new hunks
> as "undecided" so that we prompt the user to decide whether to select
> them or not.
Ok, each hunk may have {UNDECIDED,SKIP,USE}_HUNK set to denote its
current "use" state. When splitting a hunk, the new hunks always use the
previous hunk's value. This means that, if the hunk being split is
already set to skip or use, the new hunks from the split will inherit
the same value.
If a user wants to split a hunk, they likely intend to select only a
portion of the hunk. Setting each of the new hunks to same value may not
be the most intuitive behavior in this case. Resetting the hunk "use"
value results the user being prompted for each of these hunks again.
If you have a very large hunk that would get split into many smaller
hunks, this does mean that you will have to explicitly set the value for
each now. If the user only wanted to change a small portion, this could
be a bit tedious. I'm not sure this is a big setback though.
> Signed-off-by: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
> ---
> add-patch.c | 3 ++-
> t/t3701-add-interactive.sh | 10 ++++++++++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/add-patch.c b/add-patch.c
> index 95c67d8c80c..f44f98275cc 100644
> --- a/add-patch.c
> +++ b/add-patch.c
> @@ -953,6 +953,7 @@ static int split_hunk(struct add_p_state *s, struct file_diff *file_diff,
> * sizeof(*hunk));
> hunk = file_diff->hunk + hunk_index;
> hunk->splittable_into = 1;
> + hunk->use = UNDECIDED_HUNK;
Ok, we reset the current hunk to be undecided. Makes sense
> memset(hunk + 1, 0, (splittable_into - 1) * sizeof(*hunk));
>
> header = &hunk->header;
> @@ -1054,7 +1055,7 @@ next_hunk_line:
>
> hunk++;
> hunk->splittable_into = 1;
> - hunk->use = hunk[-1].use;
> + hunk->use = UNDECIDED_HUNK;
Here each of the new hunks are explicitly set to be undecided. Since we
always override the initial hunk to be undecided, I think the new hunks
would already be set undecided as well. I don't think it hurts to be
explicit though.
-Justin
> header = &hunk->header;
>
> header->old_count = header->new_count = context_line_count;
> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index b8a05d95f3f..760f3d0d30f 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -1230,4 +1230,14 @@ test_expect_success 'hunk splitting works with diff.suppressBlankEmpty' '
> test_cmp expect actual
> '
>
> +test_expect_success 'splitting previous hunk marks split hunks as undecided' '
> + test_write_lines a " " b c d e f g h i j k >file &&
> + git add file &&
> + test_write_lines x " " b y d e f g h i j x >file &&
> + test_write_lines n K s n y q | git add -p file &&
> + git cat-file blob :file >actual &&
> + test_write_lines a " " b y d e f g h i j k >expect &&
> + test_cmp expect actual
> +'
> +
> test_done
> --
> gitgitgadget
>
>
