Re: [PATCH RFC v3 18/18] builtin/history: implement "reword" subcommand

[Phillip Wood <phillip.wood123@gmail.com>]

On 16/09/2025 09:09, Patrick Steinhardt wrote:
> On Mon, Sep 15, 2025 at 03:10:56PM +0100, Phillip Wood wrote:
>> On 15/09/2025 10:32, Patrick Steinhardt wrote:
>>> On Wed, Sep 10, 2025 at 03:05:04PM +0100, Phillip Wood wrote:
>>>> On 04/09/2025 15:27, Patrick Steinhardt wrote:
>>>>> Implement a new "reword" subcommand for git-history(1). This subcommand
>>>>> is essentially the same as if a user performed an interactive rebase
>>>>> with a single commit changed to use the "reword" verb.
>>>>
>>>> The sequencer already knows how to reword a commit, it would be much simpler
>>>> to reuse that code.
>>>
>>> I'll drop the second half of this patch series for now to reduce the
>>> scope of this series a bit. But once I send the second half I'll have a
>>> look at whether this can be simplified.
>>
>> If we passed a todo-list rather than just a list of commits to the sequencer
>> then it would be as simple as writing "reword $oid"[*] in the todo-list.
> 
> One downside though is that we'll now be in interactive-rebase mode
> instead of in history-editing mode. We could of course introduce
> history-editing mode as somewhat of an alias for interactive-rebases.
> But the required changes are non-trivial and all over the place in
> "sequencer.c", so I eventually stopped pursuing that route.

I'm not sure I understand. At git-history uses the sequencer to 
cherry-pick commits by calling sequencer_pick_revisions()[1]. Both 
cherry-pick and rebase share the same todo-list format and the main loop 
in pick_commits() processes that list in the same way for both commands. 
As I said in a previous mail I think we should add a new entry point to 
the sequencer that takes a todo list rather than a list of revisions but 
that should be simple enough and then we get most of the functionality 
we want such as rewording commits and updating refs more or less for 
free. So I'm not sure what you mean by "we'll now be in 
interactive-rebase" mode.

There are good arguments for not using the sequencer at all so that we 
don't update the worktree each time we pick a commit (that would be a 
lot more work though), but I cannot currently see a good reason for the 
approach of using the sequencer to cherry-pick commits but implementing 
all the other operations separately.

Thanks

Phillip

[1] At some point we should figure out how to teach "git status" to 
distinguish between "git cherry-pick" and "git history" as I think at 
the moment both probably look like a cherry-pick.


> I still think it should be possible to at least separate out the actual
> operations and share them across the sequencer and git-history(1) so
> that we can avoid some of the duplication.
> 
> Patrick
>