Re: What's cooking in git.git (Jul 2026, #12)

On Thu Jul 30, 2026 at 2:11 AM EDT, Harald Nordgren wrote:
>> Without "--reedit-message", it will happily discard "amend!" and
>> "squash!" commit messages even though the user creating them is a strong
>> signal that they intended to use them to reword the commit.
>> "--reedit-message" is a rather verbose option name which does not make
>> sense to me as we're creating a new commit with a new message so we're
>> not re-editing anything. I've commented elsewhere that I strongly
>> dislike reusing the rebase squash message template for this command
>> where we can squash fixups into multiple different commits at the same
>> time.

I also agree with these points, but given that they were already brought
up and dismissed before, I felt it wasn't my place to try to dictate
high-level design.

I may be misunderstanding your current concern with the first sentence
Phillip, but this was (at least in part) one of the recent things
addressed in this feature [1] [2].  If we go with the assumption that the
default behavior is to squash all the changes, but abandon all context
outside that provided by the first commit, then accepting amend!
messages for that first commit seems to drive the behavior closer to
what you describe.

> Should we always do "--reedit-message" then, i.e. remove the option
> and have it as the default? Do we need a "--no-edit" switch then
> instead? Maybe not, user will then always have the editor opened and
> they can save and quit if they don't care.

A script running 'git history squash' may have a harder time with this,
though something like 'git -c core.editor=/bin/true history squash' is
at least _some_ workaround.

It would seem consistent with other git commands to offer both an --edit
and --no-edit option.  If --edit is the default, it may make sense to
offer the option anyway, for the sake of some potential future where
there exists a config 'history.editSquashMsg' (for example).  '--edit'
would then override a configured value of 'false'.  Of course, the
precedent is --reedit-message so far in 'git history'.

1: https://lore.kernel.org/git/[email protected]/
2: https://lore.kernel.org/git/[email protected]/