git stash y pop muestra el file ya no marcado como movido?

git mv file1 file2 git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: file1 -> file2 git stash git stash pop # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: file2 # # 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: file1 

Como puede ver, Git pierde la relación renombrada después de un stash / pop. ¿Hay alguna manera de recuperar esta relación, o tener escondido saber que los files se movieron? A menudo guardo para ver cuál es el estado de mi sistema como precambios, pero perderlo me causa problemas. No sé cómo solucionarlo más que borrar el nuevo file, volver a hacer un git mv y replace el contenido del nuevo file.

Si aún no ha reventado su escondite, haga lo siguiente:

 git stash pop --index 

Esto conserva correctamente las relaciones de files movidas (pero no confirmadas) en un alijo. Según git help stash :

Si se utiliza la opción –index, intenta restablecer no solo los cambios del tree de trabajo, sino también los del índice. Sin embargo, esto puede fallar, cuando tiene conflictos (que están almacenados en el índice, por lo que ya no puede aplicar los cambios como estaban originalmente).

Si ya ha reventado su escondite y desea volver a crear la relación movida, haga lo siguiente:

 git rm --cached file1 

Esto elimina el file "viejo" no movido del índice:

Utilice esta opción para eliminar y eliminar trazados solo del índice

Respuesta corta: git rm --cached file1

Todo lo que git mv realmente hace es cambiar el nombre del file (en el sistema de files) y luego agregar una eliminación y creación de files al índice (área de transición). No está especialmente marcado. Posteriormente, otra maquinaria se da count de que se trataba de un cambio de nombre, al ver que el contenido que antes se llamaba file1 se llama ahora file2.

Como los commands de git stash modifican el índice, pueden perturbar las cosas. Tenga en count que ahora tiene la creación en etapas, ¡pero no la eliminación! (Normalmente, git-stash deja todo fuera de escena después de un pop, pero en este caso creo que no tiene más remedio que poner el nuevo file en el índice, para evitar que no tenga idea de cuál conservar. Puede evitar esto alguna vez sucediendo con git stash pop --index , pero eso git stash pop --index si los cambios escondidos no se pueden aplicar limpiamente, por lo que no es el pnetworkingeterminado.) El git status ya no puede mostrarlo como un cambio de nombre, porque el cambio de nombre se divide efectivamente entre el índice y el tree de trabajo, y ninguna sección puede reclamarlo por completo.

Simplemente ejecute git rm --cached file1 para organizar la eliminación (es decir, elimine el file1 del índice) y se mostrará nuevamente como un cambio de nombre. También podría ejecutar git add -u para agregar cambios automáticamente, siempre y cuando no tenga otros cambios que no desee representar.

Tenga en count que esto significa que en la práctica no tiene que preocuparse: cuando coloca correctamente todo en preparación para comprometerse (por ejemplo, con git add -u ), el "problema" se soluciona solo.