Thanks Jeff for the comment. You are right. I oversimplified the use-case ( 
forget to fill the directory )

Sent from my iPad

On Jul 27, 2012, at 5:29 PM, Jeff King <p...@peff.net> wrote:

> On Fri, Jul 27, 2012 at 07:06:08AM +0400, Aleksandr Pryimak wrote:
> 
>> I also recreated it
>> 
>> aleksandr@beast:/tmp/test$ git init
>> Initialized empty Git repository in /tmp/test/.git/
>> aleksandr@beast:/tmp/test$ touch x
>> aleksandr@beast:/tmp/test$ git add x
>> aleksandr@beast:/tmp/test$ git commit -m "Initial"
>> [master (root-commit) d3569a0] Initial
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 x
> 
> OK, so we have "x" as a tracked file.
> 
>> aleksandr@beast:/tmp/test$ rm x
>> aleksandr@beast:/tmp/test$ mkdir x/
>> aleksandr@beast:/tmp/test$ ls
>> x
> 
> And then we remove it in favor of a directory. Note that git does not
> track directories directly, only files inside them. So from git's
> perspective, the working tree has no content in it at all.
> 
>> aleksandr@beast:/tmp/test$ git stash
>> Saved working directory and index state WIP on master: d3569a0 Initial
>> HEAD is now at d3569a0 Initial
> 
> And now we stash it. That will stash the working tree removal of x. It
> will not stash anything about the new directory x, because it has no
> content inside it.
> 
>> aleksandr@beast:/tmp/test$ ls
>> x
>> aleksandr@beast:/tmp/test$ git stash pop
>> Removing x
>> # On branch master
>> # Changes not staged for commit:
>> #   (use "git add/rm <file>..." to update what will be committed)
>> #   (use "git checkout -- <file>..." to discard changes in working directory)
>> #
>> #    deleted:    x
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>> Dropped refs/stash@{0} (c500443ae16cf0d846b195cb97eb388dec5f440e)
>> aleksandr@beast:/tmp/test$ ls
> 
> And your stash pop restores the deletion of "x". It does _not_ reinstate
> the directory "x", because as I stated above, that is not part of the
> stash.
> 
> So what is the data loss? That the "mkdir x" was lost? That has nothing
> to do with stash, but rather the fact that git does not track empty
> directories. You could see the same thing with:
> 
>  mkdir x && git commit -a
> 
> which will not record your mkdir at all. In other words, this is by
> design.
> 
> If we put actual files inside "x", which git does track, then they would
> be part of the stash, and should be properly retained. But they're not:
> 
>  $ rm x && mkdir x && echo foo >x/file
> 
> Now we have some precious contents in the form of "x/file". They are
> untracked by git, but git should be careful about removing them.
> 
>  $ git stash
>  Saved working directory and index state WIP on master: 2d32d3a initial
>  HEAD is now at 2d32d3a initial
>  $ ls -l x
>  -rw-r--r-- 1 peff peff 0 Jul 27 09:19 x
>  $ git stash show --raw
>  :100644 000000 e69de29... 0000000... D  x
> 
> Now this _is_ data loss. Stash blows away untracked files inside the
> directory, but does not record them in the resulting stash. And that
> should be fixed.
> 
> With "-u", I'd expect stash to include the untracked file x/foo in the
> stash. Without "-u", I'd expect stash to fail, since it would be
> deleting untracked files.
> 
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to