From: Junio C Hamano Date: Thu, 27 Aug 2026 16:35:42 GMT Subject: Re: [PATCH v2 1/3] commit: reword the empty-commit rebase errors Message-ID: In-Reply-To: <65c48ed3cb638cf0be18a3aa6d86d4c4f2cf01a2.1787792534.git.gitgitgadget@gmail.com> "Elijah Newren via GitGitGadget" writes: > From: Elijah Newren > > When a rebase applies a commit that becomes empty, it stops and asks the > user to decide whether to keep it or drop it. HEAD still points at the > previously-applied commit at that point, so either amending or creating > a partial commit is refused, with one of the following messages: > > You are in the middle of a rebase -- cannot amend. > cannot do a partial commit during a rebase. > > Neither message hints that the real problem is a commit that became > empty, and "during a rebase" is overly broad besides -- amending and > partial commits are fine at an `edit` or `break` stop. Reword both to > describe the actual situation. > > Signed-off-by: Elijah Newren > --- > builtin/commit.c | 4 ++-- > t/t3404-rebase-interactive.sh | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/builtin/commit.c b/builtin/commit.c > index 28f6174503..0d908d72bb 100644 > --- a/builtin/commit.c > +++ b/builtin/commit.c > @@ -521,7 +521,7 @@ static const char *prepare_index(const char **argv, const char *prefix, > else if (is_from_cherry_pick(whence)) > die(_("cannot do a partial commit during a cherry-pick.")); > else if (is_from_rebase(whence)) > - die(_("cannot do a partial commit during a rebase.")); > + die(_("cannot do a partial commit while resolving a commit that became empty.")); That is a mouthful. It also is awkward to say "while resolving a commit". More importantly, I am not sure if whence == FROM_REBASE_PICK at this point in the code flow is a sufficient sign to tell that we were not just in the middle of a rebase, not just a rebase stopped with _some_ conflict, but the way the rebase stopped was because a step in rebase resulted in a commit that is no-op relative to the previous commit. What makes us certain that the rebase-pick is empty? > @@ -1334,7 +1334,7 @@ static int parse_and_validate_options(int argc, const char *argv[], > else if (is_from_cherry_pick(whence)) > die(_("You are in the middle of a cherry-pick -- cannot amend.")); > else if (whence == FROM_REBASE_PICK) > - die(_("You are in the middle of a rebase -- cannot amend.")); > + die(_("You are resolving a commit that became empty -- cannot amend.")); > } Again "resolving a commit" sounds a bit awkward. What makes us certain that we aren't seeing an ordinary conflicted "pick" step but the one that has become empty? If "rebase -i" stopped for conflict while applying one step, you edited away conflicts in the working tree files, and instead of saying "rebase --continue" tried to run "commit --amend" by mistake, we do want to stop, but wouldn't it surprise us if the message to stop us said something about "became empty"?