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

[Phillip Wood <phillip.wood123@gmail.com>]

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