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

From: Matt Hunter <m@lfurio.us>
Date: Jul 31, 2026, 07:02 UTC
Message-ID: <DKCKB3HW6VJA.19CQLPOHR6WTI@lfurio.us>
In-Reply-To: <CAHwyqnXYi76rMOWYEgJhoh2rXaTgLbze7mKd+WGoC9BbDFHXHA@mail.gmail.com>

On Thu Jul 30, 2026 at 2:11 AM EDT, Harald Nordgren wrote:

Show 9 quoted lines

>> 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/DJY0QSJYNG0J.210HZQH198Y1N@lfurio.us/ 2: https://lore.kernel.org/git/pull.2337.v9.git.git.1784128573.gitgitgadget@gmail.com/