On Wed, Aug 11, 2021, at 22:24, Jeff King wrote: > On Wed, Aug 11, 2021 at 01:49:18PM +0000, Joel Klinghed via GitGitGadget wrote: > > > From: Joel Klinghed <the_jk@xxxxxxxxxxx> > > > > 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"? > At my work we use "fixup!" when pushing fixes to a review, using the modified body to outline what issue the commit is addressing, helping the reviewers to see intent and not just the end result. All "fixup!" are then ofc. squashed before integration. Same can be achieved with -m but --edit is generally easier to work with in my experience. I've also once or twice used it to avoid a "fixup!" of a "fixup!" instead of looking up the original target commit hash but that's just me being lazy. I'll add a test to check for previous behavior. /JK
