git/sequencer.c, branch v2.42.2

Merge branch 'ob/sequencer-remove-dead-code' into maint-2.42

2023-11-02T07:53:24Z

Code clean-up. * ob/sequencer-remove-dead-code: sequencer: remove unreachable exit condition in pick_commits()

Merge branch 'ob/sequencer-reword-error-message' into maint-2.42

2023-11-02T07:53:23Z

Update an error message (which would probably never been seen). * ob/sequencer-reword-error-message: sequencer: fix error message on failure to copy SQUASH_MSG

Merge branch 'pw/rebase-i-after-failure' into maint-2.42

2023-11-02T07:53:17Z

Various fixes to the behaviour of "rebase -i" when the command got interrupted by conflicting changes. cf. <6b927687-cf6e-d73e-78fb-bd4f46736928@gmx.de> * pw/rebase-i-after-failure: rebase -i: fix adding failed command to the todo list rebase --continue: refuse to commit after failed command rebase: fix rewritten list for failed pick sequencer: factor out part of pick_commits() sequencer: use rebase_path_message() rebase -i: remove patch file after conflict resolution rebase -i: move unlink() calls

Merge branch 'ob/sequencer-empty-hint-fix' into maint-2.42

2023-11-02T07:53:16Z

The use of API between two calls to require_clean_work_tree() from the sequencer code has been cleaned up for consistency. * ob/sequencer-empty-hint-fix: sequencer: rectify empty hint in call of require_clean_work_tree()

Merge branch 'mp/rebase-label-length-limit' into maint-2.42

2023-11-02T07:53:14Z

Overly long label names used in the sequencer machinery are now chopped to fit under filesystem limitation. * mp/rebase-label-length-limit: rebase: allow overriding the maximal length of the generated labels sequencer: truncate labels to accommodate loose refs

sequencer: remove unreachable exit condition in pick_commits()

2023-09-13T00:32:09Z

This was introduced by 56dc3ab04 ("sequencer (rebase -i): implement the 'edit' command", 2017-01-02), and was pointless from the get-go: all early exits from the loop above are returns, so todo_list->current == todo_list->nr is an invariant after the loop. Signed-off-by: Oswald Buddenhagen Acked-by: Phillip Wood Signed-off-by: Junio C Hamano

rebase -i: fix adding failed command to the todo list

2023-09-06T17:29:44Z

When rebasing commands are moved from the todo list in "git-rebase-todo" to the "done" file (which is used by "git status" to show the recently executed commands) just before they are executed. This means that if a command fails because it would overwrite an untracked file it has to be added back into the todo list before the rebase stops for the user to fix the problem. Unfortunately when a failed command is added back into the todo list the command preceding it is erroneously appended to the "done" file. This means that when rebase stops after "pick B" fails the "done" file contains pick A pick B pick A instead of pick A pick B This happens because save_todo() updates the "done" file with the previous command whenever "git-rebase-todo" is updated. When we add the failed pick back into "git-rebase-todo" we do not want to update "done". Fix this by adding a "reschedule" parameter to save_todo() which prevents the "done" file from being updated when adding a failed command back into the "git-rebase-todo" file. A couple of the existing tests are modified to improve their coverage as none of them trigger this bug or check the "done" file. Reported-by: Stefan Haller Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

rebase --continue: refuse to commit after failed command

2023-09-06T17:29:44Z

If a commit cannot be picked because it would overwrite an untracked file then "git rebase --continue" should refuse to commit any staged changes as the commit was not picked. This is implemented by refusing to commit if the message file is missing. The message file is chosen for this check because it is only written when "git rebase" stops for the user to resolve merge conflicts. Existing commands that refuse to commit staged changes when continuing such as a failed "exec" rely on checking for the absence of the author script in run_git_commit(). This prevents the staged changes from being committed but prints error: could not open '.git/rebase-merge/author-script' for reading before the message about not being able to commit. This is confusing to users and so checking for the message file instead improves the user experience. The existing test for refusing to commit after a failed exec is updated to check that we do not print the error message about a missing author script anymore. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

rebase: fix rewritten list for failed pick

2023-09-06T17:29:43Z

git rebase keeps a list that maps the OID of each commit before it was rebased to the OID of the equivalent commit after the rebase. This list is used to drive the "post-rewrite" hook that is called at the end of a successful rebase. When a rebase stops for the user to resolve merge conflicts the OID of the commit being picked is written to ".git/rebase-merge/stopped-sha". Then when the rebase is continued that OID is added to the list of rewritten commits. Unfortunately if a commit cannot be picked because it would overwrite an untracked file we still write the "stopped-sha1" file. This means that when the rebase is continued the commit is added into the list of rewritten commits even though it has not been picked yet. Fix this by not calling error_with_patch() for failed commands. The pick has failed so there is nothing to commit and therefore we do not want to set up the state files for committing staged changes when the rebase continues. This change means we no-longer write a patch for the failed command or display the error message printed by error_with_patch(). As the command has failed the patch isn't really useful and in any case the user can inspect the commit associated with the failed command by inspecting REBASE_HEAD. Unless the user has disabled it we already print an advice message that is more helpful than the message from error_with_patch() which the user will still see. Even if the advice is disabled the user will see the messages from the merge machinery detailing the problem. The code to add a failed command back into the todo list is duplicated between pick_one_commit() and the loop in pick_commits(). Both sites print advice about the command being rescheduled, decrement the current item and save the todo list. To avoid duplicating this code pick_one_commit() is modified to set a flag to indicate that the command should be rescheduled in the main loop. This simplifies things as only the remaining copy of the code needs to be modified to set REBASE_HEAD rather than calling error_with_patch(). Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

sequencer: factor out part of pick_commits()

2023-09-06T17:29:43Z

This simplifies the next commit. If a pick fails we now return the error at the end of the loop body rather than returning early, a successful "edit" command continues to return early. There are three things to check to ensure that removing the early return for an error does not change the behavior of the code: (1) We could enter the block guarded by "if (reschedule)". This block is not entered because "reschedlue" is always zero when picking a commit. (2) We could enter the block guarded by "else if (is_rebase_i(opts) && check_todo && !res)". This block is not entered when returning an error because "res" is non-zero in that case. (3) todo_list->current could be incremented before returning. That is avoided by moving the increment which is of course a potential change in behavior itself. The move is safe because none of the callers look at todo_list after this function returns. Moving the increment makes it clear we only want to advance the current item if the command was successful. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano