Re: [PATCH v2 1/3] commit: reword the empty-commit rebase errors

[Junio C Hamano <gitster@pobox.com>]

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Elijah Newren <newren@gmail.com>
>
> 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 <newren@gmail.com>
> ---
>  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"?