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

[Patrick Steinhardt <ps@pks.im>]

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

Patrick