"ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> -static void print_advice(struct repository *r, int show_hint,
> - struct replay_opts *opts)
> +static char *check_need_delete_cherry_pick_head(struct repository *r)
> {
> char *msg = getenv("GIT_CHERRY_PICK_HELP");
>
> if (msg) {
> - fprintf(stderr, "%s\n", msg);
> /*
> * A conflict has occurred but the porcelain
> * (typically rebase --interactive) wants to take care
> @@ -411,18 +409,22 @@ static void print_advice(struct repository *r, int show_hint,
> */
> refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
> NULL, 0);
> - return;
> + return msg;
> }
> + return NULL;
> +}
The patch is a bit hard to read, but I do not think this improves
the root cause of the issue at all, which is that "do we need to
delete the pseudoref?" decision is tied to and based on the presense
of the custom message in the environment variable.
The original issue was that we declared (erroneously) that the
presence of a custom message _means_ the caller is not a human but a
sequencing machinery that wants to deal with what is done via the
CHERRY_PICK_HEAD pseudoref itself, and your original issue was that
when a human user has the custom message envirnoment (either on
purpose or by mistake), the logic _misidentifies_ the call as if it
is made from a sequencing machinery and we lose the CHERRY_PICK_HEAD
pseudoref. The root cause is mistaking the correlation (sequencing
machinery uses the environment and it also does not want pseudoref)
as the causation (presense of the environment means we should remove
pseudoref).
