ask diff-index what changed between HEAD and the current index, and.Working tree by adding all changes to the index, first match what's in the index and what's in the.In the stash should be reset to their state in HEAD, previously

This behaviour was never what was intended, only blobs that also end up However if matches a file that was untracked before invoking the 'stash' command, all untracked files matching the pathspec would inadvertently be deleted as well, even though they wouldn't end up in the stash, and are therefore lost. This would work fine if the pathspec doesn't match any files that were untracked before ' git stash push - '. The call to ' git clean' was supposed to clean up the files that The intention was to emulate what ' git reset -hard - ' would Honor pathspec',, Git v2.13.0-rc0)) used the sequence of: git reset & git ls-files -modified | Git stash push ( df6bba0 ('stash: teach 'push' (and 'create_stash') to This is because the original commit introducing the pathspec feature in That match the pathspec will be deleted, even though they do not end up (Merged by Junio C Hamano - gitster - in commit 087d1a8, ) stash: don't delete untracked files that match pathspecĬurrently when ' git stash push - ' is used, untracked files See commit bba067d () by Thomas Gummerer ( tgummerer). The directory that matched the pathspec, which has been corrected. ' git stash - ' incorrectly blew away untracked files in How does git stash treat untracked files?īefore Git 2.16.x/2.17, potentially badly! In other words, the working directory state has taken precedence in the stash operation. #1 was also lost after a pair of git stash and git stash pop operations.

#2 'Hello in Working Directory (tracked)' (of t1.txt in worktree before `git stash`) Index vs Tracked (Changes not staged for commit)īy the way, note also that what happened to the state of #1 'Hello in Index' (of t1.txt in index before `git stash`) If you lost t2.txt git stash won't be able to restore it for you MINGW64 ~/proj/tmp/sandbox/tmp (f2) Note that t2.txt was not handled by git stash MINGW64 ~/proj/tmp/sandbox/tmp (f2)ġ file changed, 1 insertion(+), 1 deletion(-) Nothing added to commit but untracked files present (use 'git add' to track) Saved working directory and index state WIP on f2: 7367b85 Add t1.txt Now perform the stash MINGW64 ~/proj/tmp/sandbox/tmp (f2) ' to discard changes in working directory)

$ echo 'Bonjour in Working Directory (untracked)' > t2.txtĮxamine the four states MINGW64 ~/proj/tmp/sandbox/tmp (f2) $ echo 'Hello in Working Directory (tracked)' > t1.txt $ echo 'Hello in Index' > t1.txt git add t1.txt $ echo 'Hello' > t1.txt git add t1.txt git commit -m 'Add t1.txt' Set up four different states MINGW64 ~/proj/tmp/sandbox/tmp (f2)

The three cases (a based case, file t1.txt in history) is also included. The following experiment shows how git stash (with -u) handles See this SO article ( link) for more details. With the option -u, git stash -u can include also the untracked files. And if #1 and #2 are happening to the same file, then #2 will take precedence over #1. In other words, git stash (without the option -u) would stash #1 and #2 but not #3. But to me, the one-line describing the command should be revised to this git-stash - Stash away the tracked changes in a dirty working directory I am trying to provide my own answer here.

Git stash files