From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Tue, 21 Oct 2025 21:43:16 GMT
Subject: Re: [PATCH v5 06/12] builtin/history: implement "reword" subcommand
Message-ID: <CALnO6CBT+5i==AtF-_xEgp9nEUEZY2G4DSAsSL9dysxr8A-WfA@mail.gmail.com>
In-Reply-To: <xmqqa51kszvc.fsf@gitster.g>

On Tue, Oct 21, 2025 at 5:34 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Patrick Steinhardt <ps@pks.im> writes:
>
> > 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.
>
> Oy.  I've always wanted something like this in "rebase -i" myself.
>
> It is a bit sad that I have to learn a new command to do something
> obvious and trivial like this, but that's life ;-)
>
> Maybe "git history" becomes powerful enough and can replace my
> every-day use of "rebase -i".
>
> > @@ -9,6 +9,7 @@ SYNOPSIS
> >  --------
> >  [synopsis]
> >  git history [<options>]
> > +git history reword [<options>] <commit>
>
> It is curious that a command-less form is still listed here,
> especially since this command "requires" a subcommand.  I would have
> expected that there will be a single line here after implementing a
> single subcommand.
>
> > +`reword <commit> [--message=<message>]`::
>
> That should be `reword [--message=<message>] <commit>` no?
>
> > +     Rewrite the commit message of the specified commit. All the other
> > +     details of this commit remain unchanged. If no commit message is
> > +     provided, then this command will spawn an editor with the current
> > +     message of that commit.
>
> As long as it takes more than one -m and concatenates them just like
> "git commit -m <message1> -m <message2>" does, I would not complain
> too much that a command line option to give message encourages sloppy
> log messages.
>
> > +             if (!onto) {
> > +                     onto = commit;
> > +                     result.clean = 1;
> > +                     result.tree = repo_get_commit_tree(repo, commit);
> > +             } else {
> > +                     onto = replay_pick_regular_commit(repo, commit, replayed_commits,
> > +                                                       onto, &merge_opts, &result);
> > +                     if (!onto)
> > +                             break;
> > +             }
>
> Hmph, I would have expected that the overall flow of this command
> would be
>
>  * find the commits above and including the <commit> in question,
>    making sure there is no merge.

I don't remember offhand if the implementation supports merges, so
this might not answer the question…

> without having to touch any "pick" machinery.  Why do we need to go
> down to the merge machinery for a mere "reword" operation?

…but it would be nice to not overly restrict the commits that can be
reworded (IIRC, jj permits the equivalent).

-- 
D. Ben Knoble