Re: possible bug of git stash deleting uncommitted files in corner case

From: Remi Galan Alfonso <remi.galan-alfonso@ensimag.grenoble-inp.fr>
Date: Apr 22, 2016, 12:29 UTC
Message-ID: <1304154573.4013923.1461328186541.JavaMail.zimbra@ensimag.grenoble-inp.fr>
In-Reply-To: <CAND5yRvU1-AgvQW106fHbNN-GRQ615HjTDjR6AY9gkpoquBgDw@mail.gmail.com>

Daniele Segato <daniele.segato@gmail.com> wrote:

Show 26 quoted lines

> git init
> echo 'X' > foo
> git add foo
> git commit -m 'foo file committed'
> 
> rm foo
> mkdir foo
> echo 'B' > foo/bar
> 
> # git status
> 
> git stash
> 
> at this point stash deleted the "bar" file, in his case all the work
> on the previous couple of hours, but he didn't know yet
> 
> the foo directory was gone, replaced by the foo file
> 
> git stash pop
> 
> did not complained and deleted foo file again
> 
> I know my co-worker shouldn't had created a directory with the same
> file he was deleting but I also think git shouldn't have allowed him
> to stash at all, or should have been clever enough to actually stash
> the directory with its files.

AFAIK it is a bug.
Without even going to the stash command,
    git init
    echo 'X' >foo
    git add foo
    git commit -m "Adding foo"
    rm foo
    mkdir foo
    echo 'B' >foo/bar
    git status
At this point the state is incorrect, the file foo/bar isn't there, as
you mentionned.

>  $ git --version
> git version 1.9.1

Contrary to what I expected, this seems to still be the case with:
  $ git --version
  git version 2.8.0.rc2

Being at $daywork right now, I am unable to test this any further.

Thanks, Rémi