Re: [PATCH v5 06/12] builtin/history: implement "reword" subcommand
- From
D. Ben Knoble <ben.knoble@gmail.com>
- Date
- Oct 21, 2025, 21:43 UTC
- 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:
Show 56 quoted lines
>
> 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