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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Aug 3, 2026, 09:11 UTC
Message-ID: <ddd0160c-7f4c-41c7-855f-58288db00050@gmail.com>
In-Reply-To: <CAHwyqnXYi76rMOWYEgJhoh2rXaTgLbze7mKd+WGoC9BbDFHXHA@mail.gmail.com>

Hi Harald

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

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