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
