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

[Phillip Wood <phillip.wood123@gmail.com>]

On 30/09/2026 22:33, Junio C Hamano wrote:
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> 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".