Miklos Vajna <vmiklos@xxxxxxx> writes:
> When copy&paste goes wrong, and the user e.g. tries to cherry-pick a
> blob, the error message used to be:
It is the other way around. When the user tries to cherry-pick a
non-commit we say a correct but nonspecific "expected one commit",
and it does not matter how the user threw a non-commit at us. One
possibility could be copy&paste going wrong.
> fatal: BUG: expected exactly one commit from walk
>
> Instead, now it is:
>
> fatal: Can't cherry-pick a blob
I wonder what we would do when "git cherry-pick master: next"
is given. That is not "single commit input" case and not covered by
this patch, but perhaps something we may want to diagnose?
In other words, perhaps we would want to inspect pending objects
before running prepare_revision_walk and make sure everybody is
commit-ish or something?
>
> Signed-off-by: Miklos Vajna <vmiklos@xxxxxxx>
> ---
> sequencer.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index baa0310..0ac00d4 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1082,8 +1082,15 @@ int sequencer_pick_revisions(struct replay_opts *opts)
> if (prepare_revision_walk(opts->revs))
> die(_("revision walk setup failed"));
> cmit = get_revision(opts->revs);
> - if (!cmit || get_revision(opts->revs))
> + if (!cmit || get_revision(opts->revs)) {
> + unsigned char sha1[20];
> + if (!get_sha1(opts->revs->cmdline.rev->name, sha1)) {
> + enum object_type type = sha1_object_info(sha1, NULL);
> + if (type > 0 && type != OBJ_COMMIT)
> + die(_("Can't cherry-pick a %s"), typename(type));
> + }
> die("BUG: expected exactly one commit from walk");
> + }
> return single_pick(cmit, opts);
> }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html