Skip to content

Commit 3e2ec7b

Browse files
committed
add -p: mark split hunks as undecided
When a hunk is split, each of the new hunks inherits whether it is selected or not from the original hunk. If a selected hunk is split all of the new hunks are marked as "selected" and the user is only prompted with the first of the split hunks. The user is not asked whether or not they wish to select the rest of the new hunks. This means that if they wish to deselect any of the new hunks apart from the first one they have to navigate back to the hunk they want to deselect before they can deselect it. This is unfortunate as the user is presumably splitting the original hunk because they only want to select some sub-set of it. Instead mark all the new hunks as "undecided" so that the user is prompted whether they wish to select each one in turn. In the case where the user only wants to change the selection of the first of the split hunks they will now have to do more work re-selecting the remaining split hunks. However, changing the selection of any of the other newly created hunks is now much simpler as the user no-longer has to navigate back to them in order to change their selected state. Due to concerns that users may be relying on the current behaviour [1] this change is guarded by WITH_BREAKING_CHANGES. [1] https://lore.kernel.org/git/[email protected] Signed-off-by: Phillip Wood <[email protected]>
1 parent 4975ec3 commit 3e2ec7b

File tree

3 files changed

+22
-0
lines changed

3 files changed

+22
-0
lines changed

Documentation/BreakingChanges.adoc

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -165,6 +165,11 @@ A prerequisite for this change is that the ecosystem is ready to support the
165165
"reftable" format. Most importantly, alternative implementations of Git like
166166
JGit, libgit2 and Gitoxide need to support it.
167167

168+
* The behavior of "git add -p" has been changed so that splitting a
169+
hunk that has already been marked as selected or unselected will now
170+
prompt the user to select each of the new hunks created by the
171+
split instead of them inheriting their state from the original hunk.
172+
168173
=== Removals
169174

170175
* Support for grafting commits has long been superseded by git-replace(1).

add-patch.c

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -956,6 +956,9 @@ static int split_hunk(struct add_p_state *s, struct file_diff *file_diff,
956956
* sizeof(*hunk));
957957
hunk = file_diff->hunk + hunk_index;
958958
hunk->splittable_into = 1;
959+
#ifdef WITH_BREAKING_CHANGES
960+
hunk->use = UNDECIDED_HUNK;
961+
#endif
959962
memset(hunk + 1, 0, (splittable_into - 1) * sizeof(*hunk));
960963

961964
header = &hunk->header;
@@ -1057,7 +1060,11 @@ static int split_hunk(struct add_p_state *s, struct file_diff *file_diff,
10571060

10581061
hunk++;
10591062
hunk->splittable_into = 1;
1063+
#ifdef WITH_BREAKING_CHANGES
1064+
hunk->use = UNDECIDED_HUNK;
1065+
#else
10601066
hunk->use = hunk[-1].use;
1067+
#endif
10611068
header = &hunk->header;
10621069

10631070
header->old_count = header->new_count = context_line_count;

t/t3701-add-interactive.sh

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1301,4 +1301,14 @@ do
13011301
'
13021302
done
13031303

1304+
test_expect_success WITH_BREAKING_CHANGES 'splitting previous hunk marks split hunks as undecided' '
1305+
test_write_lines a " " b c d e f g h i j k >file &&
1306+
git add file &&
1307+
test_write_lines x " " b y d e f g h i j x >file &&
1308+
test_write_lines n K s n y q | git add -p file &&
1309+
git cat-file blob :file >actual &&
1310+
test_write_lines a " " b y d e f g h i j k >expect &&
1311+
test_cmp expect actual
1312+
'
1313+
13041314
test_done

0 commit comments

Comments
 (0)