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

On 30/09/2026 22:33, Junio C Hamano wrote:

"Harald Nordgren via GitGitGadget" [off-list ref] writes:

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?

So we could have meaningful conflict labels for "git checkout -m".

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 think having better labels for commands that are autostashing is a good use case for adding labels to "apply" but I'm not convinced there is a good use case for "pop". As you say below is anyone really going to type out the labels when they pop a stash? Scripts should probably be using "create" and "apply" rather than "push" and "pop" so are already covered.

Thanks

Phillip

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".