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

Hi Harald

On 30/07/2026 07:11, Harald Nordgren wrote:

quoted

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