Hi Philippe

On 28/03/2025 17:03, Philippe Blain via GitGitGadget wrote:

From: Philippe Blain <redacted>

Since 982288e9bd (status: rebase and merge can be in progress at the
same time, 2018-11-12), when a merge is in progress as part of a 'git
rebase -r' operation, 'wt_longstatus_print_state' shows information
about the in-progress rebase (via show_rebase_information), and then
calls 'show_merge_in_progress' to help the user conclude the merge. This
function suggests using 'git commit' to do so, but this throws away the
authorship information from the original merge, which is not ideal.
Using 'git rebase --continue' instead preserves the authorship
information, since we enter 'sequencer.c:run_git_commit' which calls
read_env_script to read the author-script file.

Good catch

Note however that this only works when a merge was scheduled using a
'merge' instruction in the rebase todo list. Indeed, when using 'exec
git merge', the state files necessary for 'git rebase --continue' are
not present, and one must use 'git commit' (or 'git merge --continue')
in that case.

Be more helpful to the user by suggesting either 'git rebase
--continue', when the merge was scheduled using a 'merge' instruction,
and 'git commit' otherwise. As such, add a
'merge_during_rebase_in_progress' field to 'struct wt_status_state', and
detect this situation in wt_status_check_rebase by looking at the last
command done. Adjust wt_longstatus_print_state to check this field and
suggest 'git rebase --continue' if a merge came from a 'merge'
instruction, by calling show_rebase_in_progress directly.

Add two tests for the new behaviour, using 'merge' and 'exec git merge'
instructions.

Nice, thanks for adding the tests

  
+test_expect_success 'status during rebase -ir after conflicted merge (exec git merge)' '
+	git reset --hard main &&
+	git checkout -b rebase_i_merge &&
+	test_commit unrelated &&
+	git checkout -b rebase_i_merge_side &&
+	test_commit side2 main.txt &&
+	git checkout rebase_i_merge &&
+	test_commit side1 main.txt &&
+	PICK=$(git rev-parse --short rebase_i_merge) &&
+	test_must_fail git merge rebase_i_merge_side &&
+	echo side1 >main.txt &&
+	git add main.txt &&
+	test_tick &&
+	git commit --no-edit &&
+	MERGE=$(git rev-parse --short rebase_i_merge) &&
+	ONTO=$(git rev-parse --short main) &&
+	test_when_finished "git rebase --abort" &&
+	FAKE_LINES="1 2 3 5 6 7 8 9 10 exec_git_merge_refs/rewritten/rebase-i-merge-side" &&
+	export FAKE_LINES &&
+	test_must_fail git rebase -ir main &&

As with the other patch this should be

	test_must_fail env FAKE_LINES=... git rebase ...

and the same for the test below. These tests show just how opaque the 
FAKE_LINES mechanism is - I've got no idea what it's doing. If it is not 
too much work it might be worth writing out the desired todo list to a 
file and using set_replace_editor. If you do that note that you can use 
tag names in the todo list you don't need to get the oid for each commit 
and you probably don't need to rebase the side branch, just the merge.

We already read and parse the done list in show_rebase_information() - 
is it possible to avoid doing that twice by setting this flag there?

The indentation here looks strange

Thanks

Phillip