16

So I stashed some untracked files using

git stash --include-untracked

and then switched to another branch.

If I look at what changes are stashed:

backend/infinispan-rar/pom.xml                     |   12 ++++++++++--
backend/pom.xml                                    |   13 +++++++++++--
backend/test/pom.xml                               |    3 +--
.../main/resources/com/mojiva/testDbContext.xml    |    6 +++---
data/mojiva.xml                                    |    2 +-
dbmigration/pom.xml                                |   16 ++++++++++------
.../main/resources/db/changelogs/issue-17544.xml   |    4 ++--
pom.xml                                            |   11 +++++++++++

I then tried to retrieve those file using

git stash pop

and get this:

backend/activator/effective.pom already exists, no checkout
backend/adverter/src/test/java/com/mojiva/presenter/RequestParamReplacerTest.java already exists, no checkout
backend/dao/.cpath already exists, no checkout
backend/dao/.e0 already exists, no checkout
backend/dao/PutObjectStoreDirHere/defaultStore/Recovery/TransactionStatusManager/#22#/0_ffffc0a86465_cfd2_5016b5cb_1 already exists, no checkout
backend/dao/dep.tree already exists, no checkout
backend/feeds-test/.e0 already exists, no checkout
backend/feeds-test/dep.tree already exists, no checkout
data/wurfl-patch.xml already exists, no checkout
run/linksDB.log already exists, no checkout
run/linksDB.properties already exists, no checkout
run/linksDB.script already exists, no checkout
Could not restore untracked files from stash

Notice that none of the files are the same?

What is going on here?

Thanks!

Kramer
  • 927
  • 2
  • 13
  • 30
  • 1
    Possible duplicate of [Cannot apply stash to working directory](http://stackoverflow.com/questions/10508903/cannot-apply-stash-to-working-directory) – Wilfred Hughes Sep 13 '16 at 17:33

4 Answers4

12

From the below mentioned blog about how to apply a stash created with -a instead of -u:

Find the stash's commit:

git log --graph --all --decorate --oneline

Check it out

git checkout <sha>

Reset parent:

git reset HEAD~1

Create a clean stash:

git stash -u

You can now checkout master and apply the new stash.

https://blog.tfnico.com/2012/09/git-stash-blooper-could-not-restore.html#!

Markus Winand
  • 8,371
  • 1
  • 35
  • 44
6

I did the exact same thing today and found no useful help. So I did this trick:

  • git checkout stash

This will create a temporary branch. then you can apply the stash on it.

  • git stash apply

  • Copy all the changed files manually somewhere safe.

  • Ignore the temporary branch and checkout to the original branch.

  • Paste the files where you found them at the first place.

Done.

This question was old. But the answer may help someone like me. so...

Arash R
  • 402
  • 6
  • 14
  • 3
    `git stash apply` step raise exactly the same error as in the question : `Could not restore untracked files from stash` – Thierry Nov 29 '17 at 10:45
  • For me, this didn't solve the `already exists, no checkout` problem. I've posted a working solution [here](https://stackoverflow.com/a/55799386/4080966). – Erik Koopmans Apr 22 '19 at 18:40
  • Thanks, after hours of searching to find a fix this is what did it for me. My untracked files were not 'applying' and I could see them within the list. Even seeing the contents of all files in the stash wouldn't show up either. Godsend, saved me a few hours of lost work. – GBrooksy Oct 13 '22 at 08:42
1

Git 2.34 takes care of another scenario leading to "Could not restore untracked files from stash":

"git stash"(man), where the tentative change involves changing a directory to a file (or vice versa), was confused, which has been corrected with Git 2.34 (Q4 2021).

See commit bee8691, commit 3d40e37, commit 4dbf7f3 (10 Sep 2021) by Elijah Newren (newren).
(Merged by Junio C Hamano -- gitster -- in commit 4a6fd7d, 03 Oct 2021)

stash: restore untracked files AFTER restoring tracked files

Signed-off-by: Elijah Newren

If a user deletes a file and places a directory of untracked files there, then stashes all these changes, the untracked directory of files cannot be restored until after the corresponding file in the way is removed.
So, restore changes to tracked files before restoring untracked files.

There is no counterpart problem to worry about with the user deleting an untracked file and then add a tracked one in its place.
Git does not track untracked files, and so will not know the untracked file was deleted, and thus won't be able to stash the removal of that file.


Before Git 2.35 (Q1 2022), "git stash apply"(man) forgot to attempt restoring untracked files when it failed to restore changes to tracked ones.

See commit 71cade5 (04 Jan 2022) by Elijah Newren (newren).
(Merged by Junio C Hamano -- gitster -- in commit 6e22345, 10 Jan 2022)

stash: do not return before restoring untracked files

Reported-by: AJ Henderson
Test-case-by: Randall S. Becker
Signed-off-by: Elijah Newren

In commit bee8691 ("stash: restore untracked files AFTER restoring tracked files", 2021-09-10, Git v2.34.0-rc0 -- merge listed in batch #10), we correctly identified that we should restore changes to tracked files before attempting to restore untracked files, and accordingly moved the code for restoring untracked files a few lines down in do_apply_stash().
Unfortunately, the intervening lines had some early return statements meaning that we suddenly stopped restoring untracked files in some cases.

Even before the previous commit, there was another possible issue with the current code -- a post-stash-apply 'git status'(man) that was intended to be run after restoring the stash was skipped when we hit a conflict (or other error condition), which seems slightly inconsistent.

Fix both issues by saving the return status, and letting other functionality run before returning.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
-3

You should be ignoring logs and other files that are not source code. Either way, you can add --force to overwrite them.

What's happening in your case is that the files you stashed, when popped, will try to overwrite files that you already have in the working folder. In case you have important work there, git will play it safe and not overwrite them blindly.

Best advice is to clean up your setup:

  1. Add files that are not source code (like log files) to your .gitignore file.
  2. Config files should have connection strings abstracted so they don't change every time you switch branches or environments (use the repo on a different machine). See smudge/clean scripts in the git attributes chapter in progit.org/book.

If you're new, keep the #git IRC channel open at webchat.freenode.net :)

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141