Re: [PATCH RFC v2 15/16] builtin/history: implement "split" subcommand

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Sep 12, 2025, 18:26 UTC
Message-ID: <CALnO6CCG=8JeRxgVfM9ayaQ6oY1iZQe3277sh=FG2YRkbbUj=g@mail.gmail.com>
In-Reply-To: <aLmMycWf-SMBw2bX@pks.im>

On Thu, Sep 4, 2025 at 8:57 AM Patrick Steinhardt <ps@pks.im> wrote:

Show 47 quoted lines

>
> On Wed, Sep 03, 2025 at 05:55:28PM -0400, D. Ben Knoble wrote:
> > On Wed, Sep 3, 2025 at 8:20 AM Patrick Steinhardt <ps@pks.im> wrote:
> > >
> > > On Tue, Aug 26, 2025 at 09:14:49AM -0400, D. Ben Knoble wrote:
> > > > On Sun, Aug 24, 2025 at 1:44 PM Patrick Steinhardt <ps@pks.im> wrote:
> > > > > diff --git a/builtin/history.c b/builtin/history.c
> > > > > index 16b516856e..6d3f44152c 100644
> > > > > --- a/builtin/history.c
> > > > > +++ b/builtin/history.c
> > > > > @@ -517,6 +527,285 @@ static int cmd_history_reorder(int argc,
> > > [snip]
> > > > > +               wt_status_collect_changes_trees(&s, old_tree, new_tree);
> > > > > +               wt_status_print(&s);
> > > > > +               wt_status_collect_free_buffers(&s);
> > > > > +               string_list_clear_func(&s.change, change_data_free);
> > > >
> > > > I think I'm supposed to see the changes between the old and new trees,
> > > > right? Does this only happen if I use the interactive machinery to
> > > > edit a hunk? When I try accepting some changes and leaving others for
> > > > the next commit I get no diff in the template.
> > >
> > > Yeah, it's supposed to show the diff between old and new tree indeed. So
> > > in theory you should see something.
> > >
> > > > I did try to add new diff lines to a hunk, and nothing showed up…
> > > > maybe I'm holding it wrong? I'm pretty sure I compiled this version.
> > >
> > > Do you maybe have a reproducer for this? It seems to work alright for
> > > me, but I wouldn't be surprised if there was a bug here. The wt-status
> > > interfaces are quite something and I was tearing my hair while trying to
> > > figure them out.
> >
> > Hm. I have a copy of these patches at
> > https://github.com/benknoble/git/tree/ps-jj. After "make DEVELOPER=1
> > -j $(nproc)" on that branch, I did
> >
> >     bin-wrappers/git history split @~3
> >     <input y,q> # once I even used "e" and added new diffs to the patch
> >     <type commit message> # no status info
> >     <exit editor>
> >
> > Then it looks like the 2nd commit gets created automatically. Maybe
> > I'm just missing how this should work? Thanks for looking at it.
>
> Weird. I used the exact same branch, command and input and did have
> status information in my editor.

Hm. I've pulled down v3, built it, and pushed to the same branch. The tip is e91e23546b (builtin/history: implement "reword" subcommand, 2025-09-04).

Now, a heavier-handed recipe:

    GIT_CONFIG_NOSYSTEM=1 GIT_CONFIG_GLOBAL=/dev/null bin-wrappers/git
-c commit.verbose=true history split @~5
    <input y,q> # once I even used "e" and added new diffs to the patch

I see the usual instructions:

# Please enter the commit message for the split-out changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # Modifications qui seront validées : # modifié : add-patch.c #

And finally I might know what happened, ha… if the "modified files" is the status information, then it has been there all along! Meanwhile, I was expecting a _diff_.

I'm actually _still_ expecting a diff with v3 and commit.verbose set, but I apologize if I've led you down a wild goose chase for the rest :)

> Note that for now the editor only asks
> for the commit message of the first commit. The second commit is
> basically retained from the original: both tree and commit message are
> the exact same, only difference is its parent.

Sensible, though I might agree that the 2nd message should be edited (mentioned elsewhere).

-- 
D. Ben Knoble