git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Joel Klinghed <the_jk@spawned.biz>
Date
Aug 11, 2021, 22:10 UTC
Message-ID
<127626db-302e-426c-a158-35f46205e1d6@www.fastmail.com>
In-Reply-To
<YRQx/jXdydxMGBmS@coredump.intra.peff.net>
On Wed, Aug 11, 2021, at 22:24, Jeff King wrote:
Show 30 quoted lines
> 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
Previous: Jeff KingNext: Jeff King
Message 3 of 19 in “commit: restore --edit when combined with --fixup”
  1. commit: restore --edit when combined with --fixupJoel Klinghed via GitGitGadget, Aug 11, 2021
  2. Jeff KingAug 11, 2021
  3. Joel KlinghedAug 11, 2021
  4. Jeff KingAug 11, 2021
  5. brian m. carlsonAug 11, 2021
  6. commit: restore --edit when combined with --fixupJoel Klinghed via GitGitGadget, Aug 11, 2021
  7. Junio C HamanoAug 12, 2021
  8. Joel KlinghedAug 12, 2021
  9. Junio C HamanoAug 12, 2021
  10. commit: restore --edit when combined with --fixupJoel Klinghed via GitGitGadget, Aug 12, 2021
  11. Phillip WoodAug 12, 2021
  12. Joel KlinghedAug 12, 2021
  13. Phillip WoodAug 13, 2021
  14. Joel KlinghedAug 13, 2021
  15. Phillip WoodAug 14, 2021
  16. Joel KlinghedAug 14, 2021
  17. commit: restore --edit when combined with --fixupJoel Klinghed via GitGitGadget, Aug 12, 2021
  18. commit: restore --edit when combined with --fixupJoel Klinghed via GitGitGadget, Aug 14, 2021
  19. Phillip WoodAug 17, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.