I have a set of debug utilities living in a git stash slot; I'm moving between branches which differ only very slightly regarding the changes in the stash. I git stash apply the top stash on the respective branch to test a feature.
However I ran into a proper merge conflict in one of the branches, but I want to prefer what's in the stash, so I want the merge-strategy "recursive" to prefer the version coming from the stash (I guess that'd be "theirs", cf. man git-merge section MERGE-STRATEGIES, subsection recursive).
Can I somehow tell git stash apply what merge strategy to use?
Yes, you can just do the merge yourself. The stash commit's named stash.
git cherry-pick -n -m1 -Xtheirs stash
Cherrypick does a merge with the cherrypick's parent as the base. Stash commits record the worktree state with two parents, the checked-out commit and the stashed index.
The -m1 tells cherrypick to use the first parent as the merge base, when as here there's any ambiguity about exactly which changes you want merged. The -n says not to commit the result.
This will produce a worktree and index with changes that match the ones in the stashed worktree. If instead you want to apply the changes in the stashed index, cherrypick stash^2 instead; alternately, if you want to apply the changes from the stashed index (i.e. the added aka staged aka indexed content) to the stashed worktree use -m2 rather than -m1.
If you want to merge only to the worktree, do
savetree=`git write-tree`
git cherry-pick -n -m1 -Xtheirs stash
git read-tree $savetree
That's enough to handle the case in the question here (applying a handy set of changes), but it doesn't completely reproduce everything stash does for you. Applying the stashed index changes only to the current index and the stashed worktree changes only to the current worktree is just plain finicky. git stash is a script in /usr/libexec/git-core/git-stash if anybody wants to see it.