Why can't stash be applied to the working directory?

Question

I cannot apply stash back to the working directory.

Little story:

First I tried to push some committed changes, but it said: "no you can't, pull first"... OK then, I'll pull things from GitHub and then push my changes. When I tried to pull, it said that I had changes that would be overwritten, and that I should stash my changes. OK, I stashed the changes... did the pull, and push the committed changes. But now, I cannot restore the uncommitted changes I was working on.

This is the error:

MyPath/File.cs already exists, no checkout
Could not restore untracked files from stash

For sure I don't yet understand all the concepts of git, they confuse me a bit... maybe I did something wrong.

It would be great if someone could help me solve this... I've been searching google and everything for more than an hour now, and I didn't come to a solution yet.

Help is much appreciated. Thanks!

Deceitful

https://mcmap.net/q/12285/-why-does-git-stash-pop-say-that-it-could-not-restore-untracked-files-from-stash-entry was really helpful for me (git checkout stash -- .) – Poucher

Answer 1

It sounds like your stash included an untracked file that was subsequently added to the repo. When you try and check it out, git rightly refuses because it would be overwriting an existing file.

To fix, you could do something like deleting that file (it's okay, it's still in the repo), applying your stash, and then replacing the stashed version of the file with the in-repo version as appropriate.

Edit: It's also possible that the file has only been created in the working tree without having been added to the repo. In this case, don't simply delete the local file, rather:

1. move it somewhere else
2. apply the stash
3. manually merge the two file versions (working tree vs. moved).

Primaveras

Is there any way I can avoid having to stash things in the future... I come from SVN, and it looks so forward... you just update, resolve conflicts, and then commit. Git can't be so hard, that I need to add 2 steps in the cycle. Thanks again! – Deceitful

@Miguel: Stashing is not an obstacle. It's an additional tool provided by Git that allows you to improve your workflow and avoid conflicts and unclean commits. git-scm.com/docs/git-stash – Chancery

While the answer is valid, I'm really not sure git is "correct" on this. The files are in the repo, so there is no danger of data loss. why not just apply the changes? See this thread - git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html – Sandstorm

I thinks this answer is not the most helpful. git stash should help to quickly backup local changes. Manually deleting a set of files to restore it breaks the flow. The git stash branch approach in the other answer sounds better, but still much more manual than desired. – Bingham

This answer worked best for me when in the same situation. After I popped the stash I went through a merge like I would have expected from the beginning. – Corona

@MiguelAngelo, the way to avoid having to stash things is to commit them to a separate branch. There's no problem with this. Most people stash because they have something in an unusable state, and want to work on something else for a while. Instead you could git checkout -b feature; git add -A; git commit -m "Working on this"; git checkout master then go back to feature when you're ready to work on it again. Branches are cheap in git, so this is no problem at all. – Passe

Answer 2

The safest and easiest way would probably be stashing things again:

git stash -u             # This will stash everything, including unstaged files
git stash pop stash@{1}  # This will apply your original stash

Afterwards if you're happy with the result you may call

git stash drop

to remove your "safe" stash.

Chancery

Thank you for this, saved me from lots of pain and suffering! – Trailblazer

stash pop will apply and drop your original stash. Just to be safe use apply instead of pop. – Lepidopteran

In fact pop is a combination of apply and drop, but will only drop if the apply worked without conflicts. But yes, apply is usually safer. – Chancery

This assumes there are no other changes in the working directory that you want to keep. For this particular question he implies (but doesn't explicitly say) he is in a clean state, but I wanted to point that out for others coming here with local changes. – Sandstorm

This only solves the problem if the conflicting problems haven't been committed. You get the exact same message when they have been committed (e.g. with a clean checkout) and then this won't change a thing... – Stefansson

This seems risky, I think https://mcmap.net/q/11482/-why-can-39-t-stash-be-applied-to-the-working-directory is a better answer – Rowel

This doesn't solve the problem of restoring untracked files - if you have the same problem (already exists, no checkout), check my solution here. – Copartner

I was having issues using git stash apply to restore all changes on my react project, but using git stash pop stash@{number} saved me a lot of work! – Blindfish

Answer 3

As mentioned by @bentolo, you can manually delete the files it is complaining about, switch branches, and then manually add them back. But I personally prefer to stay "within git".

The best way to do this is to convert the stash to a branch. Once it is a branch you can work normally in git using the normal branch-related techniques/tools you know and love. This is actually a useful general technique for working with stashes even when you don't have the listed error. It works well because a stash really is a commit under the covers (see PS).

Converting a stash to a branch

The following creates a branch based on the HEAD when the stash was created and then applies the stash (it does not commit it).

git stash branch STASHBRANCH

Working with the "stash branch"

What you do next depends on the relationship between the stash and where your target branch (which I will call ORIGINALBRANCH) is now.

Option 1 - Rebase stash branch normally (lots of changes since stash)

If you have done a lot of changes in your ORIGINALBRANCH, then you are probably best treating STASHBRANCH like any local branch. Commit your changes in STASHBRANCH, rebase it on ORIGINALBRANCH, then switch to ORIGINALBRANCH and rebase/merge the STASHBRANCH changes over it. If there are conflicts then handle them normally (one of the advantages of this approach is you can see and resolve conflicts).

Option 2 - Reset original branch to match stash (limited changes since stash)

If you just stashed while keeping some staged changes, then committed, and all you want to do is get the additional changes that where not staged when you stashed you can do the following. It will switch back to your original branch and index without changing your working copy. The end result will be your additional stash changes in your working copy.

git symbolic-ref HEAD refs/heads/ORIGINALBRANCH
git reset

Background

Stashes are commits likes branches/tags (not patches)

PS, It is tempting to think of a stash as a patch (just like it is tempting to think of a commit as a patch), but a stash is actually a commit against the HEAD when it was created. When you apply/pop you are doing something similar to cherry-picking it into your current branch. Keep in mind that branches and tags are really just references to commits, so in many ways stashes, branches, and tags are just different ways of pointing at a commit (and its history).

Sometimes needed even when you haven't made working directory changes

PPS, You may need this technique after just using stash with --patch and/or --include-untracked. Even without changing working directories those options can sometimes create a stash you can't just apply back. I must admit don’t fully understand why. See http://git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html for some discussion.

Sandstorm

This answer should be marked as solution as it provides the most helpful pointers on how to resolve a 'locked stash' most effectively. Maybe improve it by mentioning the 'simple delete solution' first and the branch solution as second option. – Bingham

"git stash branch STASHBRANCH" does not seem to work if you are facing this scenario (exactly the same error message occurs as with pop). You may have to do some git resets beforehand. – Eurythermal

+1 I got myself in a spaghetti mess with commits and changes and stashing etc etc. This got me out of it by poping the stash to a branch thanks studgeek – Grados

Thanks for the clarification about how stashes are not patches and how they are tied to the HEAD (at the time of stashing). That makes a lot of sense. – So... I suppose that there are cases where is more flexible/portable/convenient to create a patch rather than a stash (as you mentioned: when having a lot of changes), so that it can be applied anywhere (and is just a matter of resolving conflicts). Maybe git stash show -p is helping there to make stash->*patch*. – Adhere

This worked for me perfectly. One additional step I took which I am unsure if it is required, was that files added with the same name in both the original branch and in the stash, I did remove from the original branch temporarily. Then after creating the branch from the stash using [git stash branch STASHBRANCH], I merged the stashbranch into my original branch so that I could properly resolve conflicts and choose which files to take. This is important for those of us who made lots of changes to the original branch after making the stash. – Brandybrandyn

Answer 4

The solution: You need to delete the file in question, then try to stash pop/apply again and it should go through. Don't delete other files, just the ones mentioned by the error.

The problem: Git sucks sometimes. When running git stash -u it includes untracked files (cool !) but it does not remove those untracked files and does not know how to apply the stashed untracked files on top of the leftovers (not cool !), which really makes the -u option pretty useless.

Bolide

I would've accepted this answer if it was my question. Thanks @qwertzguy, your answer solved my problem, – Helles

Ran into the same issue myself, git stash pop would not apply until I deleted the files in question - then I ran into a conflict with a file which caused the stash to be rejected. But rather then removing the untracked files it left them behind.. So note to future self stay away from git stash -u – Jerilynjeritah

Bad advice if you need parts from both versions of affected files. – Moises

Worked well. Only thing is I'd add is don't delete, but move the file to /tmp or similar because this is not the time to delete stuff! Also helps with @walf's issue - you can at least manually merge if you have the old files around. – Pertain

"it does not remove those untracked files" ...and doesn't list them in git stash show. This answer made the lightbulb go on. – Huffman

plus one for Git sucks sometimes. – Sheriff

I've posted a working solution here, it restores untracked files (the already exists, no checkout problem). – Copartner

Answer 5

To apply the code differences in the stash as a patch instead, use the following command:

git stash show --patch | patch -p1

Donahoe

Usually it's better to explain a solution instead of just posting some rows of anonymous code. You can read How do I write a good answer, and also Explaining entirely code-based answers. – Octoroon

This work for me as the patch from git stash show --patch doesn't contain the untracked files. – Dividivi

This answer helped me a lot since I was unable to pop my stash due to a lot of changes in my repo since the stash had been pushed. – Dux

Answer 6

This has happened to me numerous times, I stash untracked files with git stash -u which end up being added to the repo and I can't apply the stashed changes anymore.

I couldn't find a way to force git stash pop/apply to replace the files, so I first remove the local copies of the untracked files that were stashed (be careful as it will delete any changes that haven't been committed) and then apply the stashed changes:

rm `git ls-tree -r stash@{0}^3 --name-only`
git stash apply

Finally, I use git status, git diff and other tools to check and add back portions from the removed files if there's something missing.

---

If you have uncommitted changes that you want to keep, you can create a temporary commit first:

git add --all
git commit -m "dummy"
rm `git ls-tree -r stash@{0}^3 --name-only`
git stash apply

Use whatever tools suits you to merge the previously committed changes back into the local files, and remove the dummy commit:

git reset HEAD~1

Rodmann

Answer 7

My similarly blocked pop operation was because leftover ignored files (see the .gitignore file). Git status showed me tracked and untracked, but my activities didn't clean up the ignored files.

Details: I had used git stash save -a, checked out the master to compile and see original behavior, then tried to put it all back to continue editing. When I checked out my branch and tried to pop, my ignored files were still there from before the stash save. That is because the checkout of master only affected committed files -- it didn't wipe the ignored files. So the pop failed, essentially saying it didn't want to restore my stashed ignored files on top of files that were still there. It is unfortunate that I couldn't figure out a way to start a merge session with them.

Ultimately, I used git clean -f -d -x to remove the ignored files. Interestingly, of my ~30, 4 files still remained after cleaning (buried in subdirectories). I'll have to figure out what category they are in, that they had to be manually deleted.

Then my pop succeeded.

Showpiece

Answer 8

Try this:

git checkout stash -- .

Arni

Answer 9

An easy way to get past this issue is to rename the existing conflicting file to a non-conflicting one.

In your case, rename File.cs to File.new.cs and rerun git stash apply/pop, you won't get the error this time and will have both File.cs and File.new.cs at your disposal.

Coe

Answer 10

TL;DR Android studio: Git/Uncommitted changes/Unstash changes... and selecting a stash to be applied

I had an untracked file when creating a stash. I moved to another branch but the untracked file was still there. When I returned to the first branch and tried to apply the stash from the terminal I got "error: unknown switch `e'" I deleted the untracked file but still wasn't able to apply the stash from the terminal. I successfully applied the stash using Android studio.

Cristinacristine

Answer 11

Other solution:

cd to/root/your/project

# Show what git will be remove
git clean -n

# If all is good
git clean -f

# If not all is good, see
git clean --help

# Finish
git stash pop

Goingson

The error mentioned in the question is caused by a file that exists in both the stack and the working directory. Cleaning only fixes it if this file is untracked, which is certainly not always the case (and not the OP's case, since he got the file from a pull). – Moua

Answer 12

With Git 2.14.x/2.15 (Q3 2017), qwertzguy's solution from 2014 won't be necessary anymore.

Before Q3 2017, you had to delete the file in question, then try to stash pop/apply again.
With the next Git release, you won't have to do that.

See commit bbffd87 (11 Aug 2017) by Nicolas Morey-Chaisemartin (nmorey).
^{(Merged by Junio C Hamano -- gitster -- in commit 0ca2f32, 23 Aug 2017)}

stash: clean untracked files before reset

If calling git stash -u on a repo that contains a file that is not ignored any more due to a current modification of the gitignore file, this file is stashed but not remove from the working tree.
This is due to git-stash first doing a reset --hard which clears the .gitignore file modification and then call git clean, leaving the file untouched.
This causes git stash pop to fail due to the file existing.

This patch simply switches the order between cleaning and resetting and adds a test for this usecase.

Fillin

Answer 13

The safest way to following stashing

git stash -u

This will stash all including unstaged change

git stash drop

after you are done working on it ,to remove your "safe" stash.

Harpoon

As explained in https://mcmap.net/q/11482/-why-can-39-t-stash-be-applied-to-the-working-directory, that would not always work with Git 2.14 or less. It will work with Git 2.15: https://mcmap.net/q/11482/-why-can-39-t-stash-be-applied-to-the-working-directory – Fillin