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

Hi Harald

On 30/07/2026 07:11, 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.
> 
> 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.

I've left some thoughts about the default in my reply to Matt. Whatever 
the default I don't think there is a good reason not to let the user 
override it on the commandline,

> I'm not sure about changing the template.

I know you're reluctant but I don't remembering seeing an explanation as 
to why you think the rebase template, which was designed (or more 
accurately evolved) for squashing fixups into a single target, is a good 
fit for a command that squashes fixups into multiple targets. As I've 
explained before my worry is that we end up with fragments of the commit 
message separated by a screen full of commented lines which makes it 
both hard to edit the message and difficult to get an overview of which 
commits are being squashed.

Thanks

Phillip