stash apply causing merging conflict

Question

I made a stash and then later I worked on another branch and committed changes.

now I want to get back to my normal stash and continue working on it and even commit work later.

what I used to get back to my stash is the following command :

git stash apply stash@{2}

everything worked fine , but there is 3 files that caused merge conflict .

# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)

what command should I use to restore these files into their stash state. (I don't want the current committed state) ?

Thanks in advance.

What do you mean by "squash state"? (Is "squash" a typo for "stash" here?) — torek, Apr 01 '22 at 02:24
Technically a stash is just a small set of commits. One can see it in a graphical view in `gitk --all`. So you can either jump right to the top commit of a stash with `git reset --hard ` or just hard reset your working branch to the last commit before the stash (again with `git reset --hard ....`) and then use `git stash pop` — user3159253, Apr 01 '22 at 02:40
My experience suggests that when a stash fails to apply cleanly, then most likely it's applied to a wrong place, e.g. one didn't change a working branch back to one that was active when the stash was created. Observing the "whole picture" in a graphical view, like `gitk --all` helps to understand the reason of the mistake and fix it. — user3159253, Apr 01 '22 at 02:50
Does this answer your question? [How to resolve merge conflicts in a Git repository](https://stackoverflow.com/questions/161813/how-to-resolve-merge-conflicts-in-a-git-repository) — 1615903, Apr 01 '22 at 04:07

score 0 · Answer 1 · answered Apr 01 '22 at 18:15

First, let me quote a bit of the git stash documentation:

DISCUSSION

A stash entry is represented as a commit whose tree records the state of the working directory, and its first parent is the commit at HEAD when the entry was created. The tree of the second parent records the state of the index when the entry is made, and it is made a child of the HEAD commit. The ancestry graph looks like this:
       .----W
      /    /
-----H----I
where H is the HEAD commit, I is a commit that records the state of the index, and W is a commit that records the state of the working tree.

The stash ref (refs/stash, or in your case, stash@{2}) then points the W commit. I prefer to draw this as:

...--G--H   <-- branch (HEAD)
        |\
        i-w   <-- refs/stash

myself (showing the setup immediately after your git stash push command completes successfully), but the information here is the same.

With that in mind: If you're quite certain you want your current working tree copy overwritten with the copy of the file in the W commit of stash@{2}, you can simply run:

git checkout stash@{2} -- path/to/file.ext

or:

git restore -SW --source=stash@{2} path/to/file.ext

Note that depending on your shell, the stash@{2} expression may need some kind of quoting, e.g., --source='stash@{2}'.

Note also that you can view this version of the file with:

git show stash@{2}:path/to/file.ext

before taking any other action.

stash apply causing merging conflict

1 Answers1

DISCUSSION