Re: [PATCH] commit: restore --edit when combined with --fixup

[Jeff King <peff@peff.net>]

On Wed, Aug 11, 2021 at 01:49:18PM +0000, Joel Klinghed via GitGitGadget wrote:

> From: Joel Klinghed <the_jk@spawned.biz>
> 
> Recent changes to --fixup, adding amend suboption, caused the
> --edit flag to be ignored as use_editor was always set to zero.
> 
> Restore edit_flag having higher priority than fixup_message when
> deciding the value of use_editor by only changing the default
> if edit_flag is not set.

This is definitely a change in behavior due to 494d314a05 (commit: add
amend suboption to --fixup to create amend! commit, 2021-03-15). That
was in v2.32.0, so it's not a regression in the upcoming v2.33 which
needs to be handled in the next few days.

My inclination is to call it a regression and restore the original
behavior. But when I was going to suggest that you add a test, it made
me wonder: what would we be testing for?

If the user says "git commit --fixup HEAD --edit", it seems reasonable
for them to expect that the editor is run, and that is easy to check.
But what are they planning to edit? If they modify the subject line of
the commit, it will wreck the "fixup!" mechanism. If they modify the
body (which starts blank), it's going to be discarded by the fixup
operation.

Is the goal that they might leave notes for themselves, which they can
view in the meantime before they run "rebase --autosquash"?

-Peff