git stash --include-untracked possible destructive behavior

One of our users has just discovered a destructive behavior of git stash --include-untracked: ignored files within non-ignored directories will not be stashed as untracked files (expected), but will still be removed from the working tree. The problem is reproducible by following command sequence:

   $ git init
   $ echo "1" > file.txt
   $ mkdir Data
   $ echo "1" > Data/ignored.txt
   $ echo "Data/*" > .gitignore
   $ git add .
   $ git commit -m "initial import"
   $ echo "2" > file.txt
   $ git stash save --include-untracked
   Saved working directory and index state WIP on master: 6ce5303 initial
   import

   $ git stash show stash@{1}
    file.txt | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

   $ ls Data
   ls: cannot access 'Data': No such file or directory

As you can see, after saving the stash, stash@{1} doesn't contain Data/ignored.txt, but the entire Data directory is still gone from the working tree. As a consequence, applying the stash won't bring back Data/ignored.txt, too.

   $ git stash apply
   On branch master
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git checkout -- <file>..." to discard changes in working
     directory)

           modified:   file.txt

   no changes added to commit (use "git add" and/or "git commit -a")

   $ ls Data
   ls: cannot access 'Data': No such file or directory

Note that when changing .gitignore to "Data/" instead of "Data/*", --include-untracked works as expected.

Tested with: git version 2.13.0.windows.1

-Marc

It looks like it's an issue with git clean, as that's what stash uses internally. You can try your same test, but replace git stash with "git clean -df" and it will delete Data. Maybe clean should check if there are any ignored files in an untracked directory and only remove it if -x is specified?

Joel

On 06/08, Joel Teichroeb wrote:

There was someone working on fixing clean, you can look at the patch series at https://public-inbox.org/git/20170523100937.8752-1-sxlijin@gmail.com/ though I'm unsure of the series' status.

Looks like that series was merged last week, fixing this issue.

Marc, the fix will probably be in git 2.14.

Joel

On 09.06.2017 00:39, Joel Teichroeb wrote:

Thanks, I can confirm that with current master "git clean" as well as "git stash" are working properly now (tested on Linux). I'm looking forward to version 2.14.

-Marc