Question

Sometimes git stash fails even though I can manually make a backup of the project folder with the uncommitted changes, and then call “Undo Uncommitted Changes”.

This happens, for example, if I add a new file foo.cpp to my project. When I want to stash the changes later I get an error. This is from the Version Control output pane in Qt Creator:

14:07 Executing in C:\MyProject: git.exe add --intent-to-add foo.cpp
14:07 Executing in C:\MyProject: git.exe stash save QtCreator 2013-02-05T14:07:18
Cannot stash in "C:\MyProject": error: Entry 'foo.cpp' not uptodate. Cannot merge.
Cannot save the current worktree state

Isn’t the point of git stash to automate this process, why would it fail when simply undoing the changes succeeds?

Answer 1

--intent-to-add has left foo.cpp in a not-added-but-still-tracked state. (Do git cat-file -p $(git write-tree): foo.cpp is, correctly, not there. Do git status: it’s tracked. But I believe nobody’s taught git stash to remember that, and as a result merging the state it saves would leave foo.cpp not tracked. Since git stash pop actually does a merge into the index and worktree — you can stash your changes, parented off the current HEAD, check out something else entirely, and then do git stash popto apply the changes in the stashed content to that new worktree — the message you’re seeing is from a test-flight merge stash runs to verify that an immediate git stash pop would leave your worktree and index as they were. But in this case, it won’t. foo.cpp is tracked in your index, and absent in the stashed tree. When merging in that tree (in the absence of the intent-to-add data), the only sane thing to do is to interpret it as a deletion. But you have made changes to a file you asked to have tracked: merge can see you’d lose content you’ve told git you care about. So the merge refuses to run until you either delete the file yourself or commit it to the repository, and stash is refusing to create a stash you can’t safely pop.