Cannot apply stash to working directory

I cannot apply stash back to the working directory.

Little story:

  • Accept all merge conflicts in git
  • Can vim diff use the patience algorithm?
  • Any way to automatically merge approved nonconflicting Gitorious merge request?
  • Testing a post-merge hooks script for git
  • Create fake commits from graph
  • Fetch from one git server and push to another server using Jenkins
  • First I tried to push some commited 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 the I had changes that would be ovewritten, and that I should stash my changes. Ok, I stashed changes… did the pull, and push the commited changes. But now, I cannot restore the uncommited 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!

  • Creating a git repository in a parent folder of another git repository and removing the child repository but integrating its history into the parent
  • Build Github Package as Maven using Jitpack
  • How can I learn to understand how Mercurial works, as an experienced git user?
  • Codaset, Codebasehq, Unfuddle, Trac or Redmine?
  • How do you squelch git's automatic merge message?
  • How to execute a command right after a fetch or pull command in git?
  • 7 Solutions collect form web for “Cannot apply stash to working directory”

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

    As mentioned by @blahdiblah, 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.

    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.

    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.

    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.

    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.

    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
    
    Git Baby is a git and github fan, let's start git clone.