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 <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html