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

Hi Matt

On 31/07/2026 08:02, Matt Hunter wrote:
> 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.

If you raise a point and it is dismissed without a convincing 
explanation then its fine to raise it again asking for more details so 
that you can understand the reason behind the decision. That often leads 
to a productive discussion and an improved 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.

My feeling is that "amend!" and "squash!" commit messages indicate that 
the user intended to use them when they squashed so I think we should be 
a bit more careful about dropping them compared to other messages.

>> 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.

Can't the script just pass --edit/--no-edit?

> 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'.

That precedent is unfortunate, "--reedit-message" makes sense for the 
"fixup" subcommand because we are reediting an existing message but 
that's not the case with the "squash" subcommand where we're 
constructing a new message from several commits. Given how new the 
"fixup" subcommand is I'm tempted to add an "--edit" option and 
deprecate "--reedit-message".

Having thought about it a bit over the weekend I wonder if the best 
solution when squashing is to default to looking at the commits being 
squashed before deciding whether to open the editor or not and allow the 
user to override that on the commandline like "git commit". If we're 
squashing a bunch of "fixup!" and/or "amend!" commits into a single 
target then I'm not sure its worth opening the editor, but if we're 
squashing other commits together then it probably makes sense to open 
the editor so the user can check the result. I guess the danger is it 
ends up being confusing.

Thanks

Phillip

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