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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sep 16, 2025, 08:42 UTC
Message-ID: <cfcfaa43-7a16-408c-8d8a-325549a7838d@gmail.com>
In-Reply-To: <aMkbOgLlDDRlqt7a@pks.im>

On 16/09/2025 09:09, Patrick Steinhardt wrote:

Show 23 quoted lines

> 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.

Show 6 quoted lines

> 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
>