Re: [PATCH 0/1] rebase: add --[no-]edit to --continue

On 21/07/2026 19:04, Junio C Hamano wrote:
> Hugo Sales <[email protected]> writes:
> 
>> When a rebase stops for conflicts and the user runs `git rebase --continue`, the
>> merge backend opens $EDITOR so the commit message can be revised. That is often
>> useful, but not always: sometimes the user only wants to keep the message that
>> is already there.
>>
>> This series adds:
>>
>> - `git rebase --continue --no-edit` to commit without opening an editor
> 
> Meh. "GIT_SEQUENCE_EDITOR=: git rebase --continue" is your friend ;-)

Do you mean "GIT_EDITOR=:"? The sequence editor is only relevant for 
editing the todo list. The last time this came up [1] I shared an alias 
that only suppresses the editor if HEAD has not changed since the user 
continued the rebase, but that does not stop the user suppressing the 
editor when continuing a "reword" command. I share the concerns you 
listed below about this patch in its current form.

Thanks

Phillip

[1] 
https://lore.kernel.org/git/[email protected]

>> - `rebase.noEdit` to make that the default on continue
>> - `git rebase --continue --edit` to override `rebase.noEdit`
> 
> The new 'rebase.noEdit' configuration is especially concerning.  It
> encourages users to assume by default that their rebase sessions
> will not produce notable changes worth recording in the commit logs.
> 
> A few immediate edge cases come to mind:
> 
>   - What if 'rebase -i' stops to give control back to the user for
>     reasons other than a merge conflict?  If the user chose 'edit',
>     their original intent was to modify both the commit message and
>     the content.  With 'rebase.noEdit' enabled, would they now have
>     to remember to pass '--edit' when continuing?  Does the answer
>     depend on whether the 'edit' step resulted in a merge conflict?
> 
>   - What if the user chose 'reword', which is an explicit signal to
>     update the commit message, but 'rebase.noEdit' is enabled?  If
>     the rebase does not stop with a conflict, it might open the
>     editor regardless of the configuration.  But if a conflict does
>     occur and requires manual resolution, will the user still need to
>     remember to pass '--edit' when continuing?
> 
> The proposed tests only cover the code path where control returns to
> the user due to a conflict.  This is understandable since that
> scenario was your primary motivation.  However, they do not verify
> what happens when there are no conflicts but the user explicitly
> intended to edit the message from the start.  You may want to expand
> the test coverage to address these scenarios (and potentially
> others, as this is not an exhaustive list).
> 
> Thanks.
>