Re: [PATCH v5 0/4] history: add squash subcommand to fold a range

Hi Matt

On 30/06/2026 03:55, Matt Hunter wrote:

I haven't experimented much with the new 'git history' commands, but
this discussion caught my eye and wanted to chime in.  (aka: please
forgive my stupid questions)

Note: I have built and am testing with v6 of this topic.

Thanks for testing it, and also for your questions - it is always 
helpful to get the perspective of someone using the command, especially 
while we're still designing it.

[...] 
I agree with this idea as well.  And letting fixup! messages completely
fall out makes more sense here than I want to say in git rebase.  The
commented list of commits at the top is a nice compromise for the todo
list you would have seen had you run 'git rebase -i' instead, and a
glance at the list would confirm that the fixup!s you thought you
included _actually are_ in the squash range.

I assume the same treatment would _not_ be completely given to squash!
messages, since there is at least some expectation that they carry an
additional remark that the author might want to reword into the base
commit?

Yes for "squash! Some commit" I think we'd want to have

     Some commit

     Some commit body

     # squash! Some commit

     The body of the squash! commit

Given the above, and how 'git rebase' usually works, I'm suprised that
--reedit-message isn't the default behavior.  This may be my bias
towards rebase showing...  Perhaps the typical use of this command is to
just work fast, and expect a follow up 'git history reword' if needed -
when the original just needs a little extra context?

That's a good point - if we want to encourage good commit histories then 
opening the editor by default gives the user an opportunity to double 
check which commits are being squashed and edit the message as appropriate.

"--reedit-message" is a bit of a mouthful - maybe we should call it 
"--edit" (or "--no-edit" if we want to open the editor by default) like 
"git commit"

This is probably a larger question, since (according to the man page) it
affects the other 'git history' commands as well.  When I run
'git history ...' and discover that I made a mistake after inspecting
the results, is there a fool-proof way to undo the change and return to
the previous state?  My first thought was to run 'git reset --hard ...',
but the default behavior of --update-refs (moving other branches) can
make this more complicated.

Yes this is a problem to which we don't have a good solution at the 
moment. I believe Jujitsu and git-branchless both have some kind of 
operations log that lets you revert a whole operation rather than just a 
single ref-update. We'd need some way to tie all the ref updates from a 
single ref transaction together either by logging the separately or 
adding some form of transaction id to the reflog. That would be a big 
change.

Thanks

Phillip