Is there a way I can intentionally cause a merge conflict with a file inside my stash?

63 Views Asked by At

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?

1

There are 1 best solutions below

2
NerdyDeeds On

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:

git stash show -p | git apply -3 && git stash drop

This is close to what I'd wanted, although it would:

  1. Merge the wrong stash,
  2. Fail in its application of same, and then
  3. Delete the newer stash (which I'd not wanted involved to begin with), and
  4. It doesn't induce merge conflicts. It behaves as though I'd told it to "accept both", file-wide.

To resolve these issues:

  1. Let's change the target stash:

    git stash show -p stash@{2} # This will select the stash 2 nodes back, 
                                # and create a patch from it.
    
  2. 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 -C1 flag to the git apply statement. So:

    git apply -3 -C1
    

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

  3. I don't wish to drop the relevant stash, so I'll just omit the && git stash drop

In this particular case, I did want to accept all from both. But my search for inducing a traditional conflict continues.