| Message ID | pull.1014.git.1628689758413.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | commit: restore --edit when combined with --fixup | expand |
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
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@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"? > 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
On Thu, Aug 12, 2021 at 12:10:28AM +0200, Joel Klinghed wrote: > > 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. Ah, thanks for explaining. That makes sense. > I'll add a test to check for previous behavior. This is what I worked up, in case it helps. diff --git a/t/t7502-commit-porcelain.sh b/t/t7502-commit-porcelain.sh index 38a532d81c..3e4364066f 100755 --- a/t/t7502-commit-porcelain.sh +++ b/t/t7502-commit-porcelain.sh @@ -940,4 +940,22 @@ EOF ) ' +test_expect_success 'commit --fixup respects --edit' ' + echo broken >foo.c && + git add foo.c && + git commit -m "wip of foo.c" && + echo fixed >foo.c && + ( + test_set_editor "$TEST_DIRECTORY/t7500/add-content" && + git commit --fixup HEAD --edit foo.c + ) && + cat >expect <<-\EOF && + fixup! wip of foo.c + + commit message + EOF + git log -1 --pretty=format:%B HEAD >actual && + test_cmp expect actual +' + test_done -Peff
On 2021-08-11 at 22:10:28, Joel Klinghed wrote: > 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. Yeah, I do exactly the same thing. I want to write a nice explanation of the change I made for the reviewer, but I don't want to preserve it for the future. I recently had a series that was 33 commits after squashing but with 117 before squashing, thanks to a series of very thorough and thoughtful reviews, so in this kind of scenario, it can really be kind to the reviewer to help them match up the change with their comment. > 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. Thanks for catching this.
diff --git a/builtin/commit.c b/builtin/commit.c index 190d215d43b..4c5286840c5 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1333,7 +1333,8 @@ static int parse_and_validate_options(int argc, const char *argv[], } else { fixup_commit = fixup_message; fixup_prefix = "fixup"; - use_editor = 0; + if (0 > edit_flag) + use_editor = 0; } }