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

["Matt Hunter" <m@lfurio.us>]

Hi!

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.

On Mon Jun 29, 2026 at 3:48 PM EDT, Phillip Wood wrote:
> On 29/06/2026 19:03, Harald Nordgren wrote:
>>> So instead of
>>>
>>>       # This is the combination of 4 commits
>>>       # This is the first commit message
>>>       Base subject
>>>
>>>       Base body
>>>
>>>       # This is the second commit message
>>>       # Another subject
>>>
>>>       # Another body
>>>
>>>       # This is the third commit message
>>>       # fixup! Base subject
>>>
>>>       # This is the fourth commit message
>>>       # amend! Another subject
>>>       A better subject
>>>
>>>       A better body
>>>
>>> We'd have
>>>
>>>       # This is the combination of 4 commits
>>>       # 123 Base subject
>>>       # 456 Another subject
>>>       # 789 fixup! Base subject
>>>       # abc amend! Another subject
>>>
>>>       Base Subject
>>>
>>>       Base Body
>>>
>>>       Another subject
>>>
>>>       Another Body
>> 
>> I think this makes it a lot harder to read. If every commit body was
>> always just a single paragraph it could make sense, but it's generally
>> not. Look at the commits in this series, with no delimiter of where
>> one commit message ends and the next one starts, it would be very
>> confusing.
>
> You've trimmed the line where I said
>
>  >> Possibly with a comment before each message saying where it came
>  >> from.
>
> So I'm not against adding a comment before each message, but I do think 
> we should omit any messages that would be commented out completely. If 
> you look at the rebase example above you can see there is a mass of 
> comments between the two pieces of text that make up the new message. 
> That makes it hard to see what is actually going to be included in the 
> new message.

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?

>
> Thanks
> Phillip

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?

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.

Thanks