Re: [PATCH] stash: allow custom conflict labels for pop

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

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Since 13817db274 (stash: add --label-ours, --label-theirs, --label-base
> for apply, 2026-04-28), "git stash apply" accepts custom labels for
> conflict markers, but "git stash pop" does not, although it applies the
> entry the same way and only differs by dropping it afterward. A caller
> that wants its own labels has to use apply and drop the entry itself.
>
> Teach "git stash pop" the same three options.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
>     stash: allow custom conflict labels for pop
>     
>     git stash pop now accepts the conflict label options that git stash
>     apply gained in 2.55.

This is not a new problem, but is it just me who finds this
"feature" more about "because we can do it", not "because we need to
have it"?  Stepping back a bit, why did we add these three options
to "stash apply" in the first place?

If there is no good use case, perhaps what we should be doing is to
remove from "git stash apply" these three options, not adding the
same to another command.

I know that the underlying machinery to allow different labels were
invented for "checkout" that automatically stashes and then pops
while switching branches, and the "checkout" command wanted to use
labels that are different from what "git stash pop/apply" uses.  So
I would not question that there is a very good use case for the
underlying machinery to allow us to use different labels.

But was it really helpful and necessary, beyond "Having the feature
exposed to lower level component command like 'stash apply' makes it
slightly easier to debug", to add these three options to the "git
stash apply" command in the first place?  Who in their right mind
would type

    $ git stash pop --label-base=B --label-ours=O --label-theirs=T

every time they unstash a saved change?

Maybe I am not seeing an obvious use case, but I would blame the
lack of justification in the proposed log message for that.  And "We
can add the same three options" is not it.  "A caller that wants its
own labels has to..." is not it either.  Why does that caller want
such a strange thing?  What we have in the proposed log message is
exactly "because we can" and not "because we need them in order to
do X".