[PATCH 0/1] commit: allow -m/-F with --fixup=amend: or reword:
- From
- erik@cervined.in <erik@cervined.in>
- Date
- May 18, 2026, 11:22 UTC
- Message-ID
- <20260518112225.73172-2-erik@cervined.in>
From: Erik Cervin-Edin <erik@cervined.in>
The commit --fixup=reword: (and --fixup:amend) options are powerful but currently not well-suited for non-interactive workflows.
I often find myself hacking away on a branch and the last thing I do is finalize and formulate the commit messages. One of the current ways of doing this is running an interactive rebase and picking the commits in your branch to reword. However, doing this requires you to linearly go through the messages and edit them one by one. The other options which allows more flexible editing is to generate linear patches -- but this trades editing freedom for branch topology freedom and has its own drawbacks.
The --fixup=reword: flag introduced in 494d314a05 (commit: add amend suboption to --fixup to create amend! commit, 2021-03-15), adds a third workflow which allows rewording commits without initiating a rebase and from the comfort of the HEAD of the branch. However, doing such editing is only possible using $EDITOR, which restricts its use in some workflows.
When amend:/reword: were introduced in Charvi's series, -m support for amend fixups was discussed but not pursued (xmqqwnuvsw0d.fsf@gitster.g and xmqqczwmsjzl.fsf@gitster.g):
On Fri, 26 Feb 2021 11:32:30 -0800, Junio C Hamano wrote:
Show 26 quoted lines
> >> > + if (have_option_m)
> >> > + die(_("cannot combine -m with --fixup:%s"), fixup_message);
> >> > + else
> >> > + prepare_amend_commit(commit, &sb, &ctx);
> >>
> >> Hmph, why is -m so special? Should we allow --fixup=amend:<cmd>
> >> with -F (or -c/-C for that matter), or are these other options
> >> caught at a lot higher layer already and we do not have to check
> >> them here?
> >
> > yes, those options are caught earlier and give the error as below:
> > "Only one of -c/-C/-F/--fixup can be used."
> > and only `-m` is checked over here.
>
> And the reason why -m cannot be checked early is because we do not
> recognize which kind of "fixup" we are doing when "only one of
> -c/-C/-F/--fixup" check is made before this function is called?
>
> OK. I wonder if we can tell which kind of fixup we are doing much
> earlier, though. Then we could extend it to say "Only one of
> -c/-C/-F/-m/--fixup=amend:<commit> can be used", etc., and we do not
> have to have this "only -m is checked here, everything else is
> checked earlier" curiosity. But I do not know if such a change is
> necessarily an improvement. I guess a better "fix" would probably
> be to add a comment to this function where it only checks for "-m"
> and tell readers why -c/-C/-F do not have to be checked here.This patch picks up that thread by allowing both -m and -F for amend/reword fixups, bypassing the need for an interactive editor. This makes it practical to, for example, write replacement messages in files and batch-apply them as reword fixups without stepping through each one interactively. It's also friendly to AI agents who have a hard time editing text using a non-interactive $EDITOR.
Allowing -c/-C was also considered but left out of this patch -- it can be added in a re-roll if reviewers think it's worthwhile. I could see it being useful, for example if you want to use git notes as a re-write commit message channel. Since this is my first patch I intentionally thought it best to start small.
Erik Cervin-Edin (1): commit: allow -m/-F with --fixup=amend: or reword:
Documentation/git-commit.adoc | 13 +++-- builtin/commit.c | 41 ++++++++++---- t/t7500-commit-template-squash-signoff.sh | 67 +++++++++++++++++++---- 3 files changed, 92 insertions(+), 29 deletions(-)
-- 2.54.0.772.g683d7313b1