2017-07-07 9 views
0

Disons que j'ai cette structure de répertoire:répertoires Sibling perdus après git stash du répertoire courant

 
project_root 
| 
+--parent 
    | 
    +--child 
    | 
    +--baby_brother 

baby_brother est un nouveau répertoire, untracked par git. J'ai aussi beaucoup de changements aux fichiers dans child. Je avais besoin d'un accès temporaire aux versions précédentes des fichiers dans child, donc je pensais que je venais de planque mes changements:

cd $project_root/parent/child 
git stash push . 

Puis, plus tard:

cd $project_root/parent/child 
git stash pop 

Maintenant, à ma grande consternation, baby_brother est manquant, avec une semaine de travail. :-(

J'ai deux questions:

  1. Est-il possible d'obtenir mes fichiers, je soupçonne que la réponse est « non »

  2. Est-ce un bug ou fait. Je fais quelque chose de mal?

Je l'ai vu an SO question qui dit qu'il est prévu pour le comportement git pour supprimer des fichiers non suivis, mais pour un, il dit aussi cela a été fixé à 1.7.1.1 (j'utilise 2,13. 0), et pour deux, je m'attendais à ce que la cachette n'affecte que child, puisque j'étais dans ce répertoire et incluais un point à la fin de la commande pour référencer le répertoire courant.


Voici une repro rapide qui illustre le problème:

 
1 ~ % mkdir project_root 
2 ~ % cd project_root 
3 project_root % mkdir parent 
4 project_root % touch parent/file 
5 project_root % mkdir parent/child 
6 project_root % touch parent/child/file2 
7 project_root % git init 
Initialized empty Git repository in /home/pdaddy/project_root/.git/ 
8 project_root % git add . 
9 project_root % git commit -m 'Get it in git' 
[master (root-commit) 2d0872c] Get it in git 
2 files changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 parent/child/file2 
create mode 100644 parent/file 
10 project_root % mkdir parent/baby_brother 
11 project_root % touch parent/baby_brother/file3 
12 project_root % touch parent/file4 
13 project_root % touch file5 
14 project_root % comment="As it turns out, file4 and file5 will be deleted, too." 
15 project_root % tree $PWD 
/home/pdaddy/project_root 
|-- file5 
`-- parent 
    |-- baby_brother 
    | `-- file3 
    |-- child 
    | `-- file2 
    |-- file 
    `-- file4 

3 directories, 3 files 
16 project_root % echo 'some changes' >> parent/child/file2 
17 project_root % cd parent/child 
18 child % git stash push . 
Saved working directory and index state WIP on master: 2d0872c Get it in git 
19 project_root % tree ~/project_root 
/home/pdaddy/project_root 
`-- parent 
    |-- child 
    | `-- file2 
    `-- file 

2 directories, 2 files 
20 child % git stash pop 
On branch master 
Changes not staged for commit: 
    (use "git add ..." to update what will be committed) 
    (use "git checkout -- ..." to discard changes in working directory) 

     modified: file2 

no changes added to commit (use "git add" and/or "git commit -a") 
Dropped refs/[email protected]{0} (80e41d0ed1f2b0a085d4f5ca3a38833a18873f98) 
21 child % tree ~/project_root 
/home/pdaddy/project_root 
`-- parent 
    |-- child 
    | `-- file2 
    `-- file 

2 directories, 2 files 

Répondre

0

Je l'ai testé mon exemple repro avec la branche de git next (le v2.14.0.rc0), et le problème ne se présentait pas, donc je suppose que c'est un bug, et quelqu'un a commis une correction.