I have a single SCSS file inside my stash, a few stashes back. Let's call it target.scss. It is the only file therein and contains a small handful of modified selectors.
I have since modified target.scss.
What I'd like to do is git merge stash@{2} (its location), and have git treat it like any other merge. That is to say, I want Git to report a conflict, so I can resolve the conflict then git add, commit, and push.
I know there are other ways to do this. Yes, I can commit and apply. Yes, I can spin up a new branch, apply and rebase. Or even merge. But I'm hoping to avoid the need to commit prior to performing the merge.
Does a pattern exist in which I can trigger a merge from my stash into my presently-dirty HEAD, handle the merge conflicts, and then commit as though I'd simply manually merged them?
I can diff the file with a git diff stash@{2} target.scss, but I cannot work out how to put git into "merge conflict" mode to resolve same. Should I be looking at diff instead of merge?
I'm answering this, but all credit goes to jonrsharpe, who pointed me to this post from muhqu which came very close to offering me an answer; I just needed to tweak it a bit.
The other answer suggested:
This is close to what I'd wanted, although it would:
To resolve these issues:
Let's change the target stash:
Because it's an older stash, I needed to reduce the strictness of the patch's willingness to apply. This can be done by amending a
-C1flag to thegit applystatement. So:This is essentially telling Git, "So long as any line within this file matches, presuppose it's a valid application. Attempt to merge using a 3-way merge. Fall back to a vanilla merge otherwise."
I don't wish to drop the relevant stash, so I'll just omit the
&& git stash dropIn this particular case, I did want to accept all from both. But my search for inducing a traditional conflict continues.