On Thu, Sep 4, 2025 at 8:57 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > 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@xxxxxx> 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@xxxxxx> 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
