Git descarta cambios en el submodule del directory de trabajo

Estoy trabajando en un submodule y tengo problemas para rastrear una carpeta llena de files

$ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: public/javascripts/app/fckeditor/editor/skins/office2003/fck_dialog.css # modified: public/javascripts/app/fckeditor/editor/skins/office2003/fck_editor.css # modified: public/javascripts/app/fckeditor/editor/skins/silver/fck_dialog.css # modified: public/javascripts/app/fckeditor/editor/skins/silver/fck_editor.css # modified: public/javascripts/app/fckeditor/fckconfig.js # modified: public/javascripts/app/fckeditor/fckeditor.js # modified: public/javascripts/app/fckeditor/fckpackager.xml 

yo tecleo

 git reset --hard 

que devuelve

HEAD ahora está en b2c5a77 nada

Sin embargo, cuando escribo

 git status 

Nuevamente me saludan con la larga list de files. He intentado

 git clean -f 

y también eliminó todo el submodule y lo desprotegió del server maestro. También intenté eliminar todo el proyecto a quien pertenece el submodule, lo extraje y luego inicié y actualicé el submodule, pero fue en vano.

 rm -rf project git clone foo@bar.project.net:/home/rails/repo/gits/project.com #Cloning into project... #remote: Counting objects: 2452, done. #remote: Compressing objects: 100% (2040/2040), done. #remote: Total 2452 (delta 1238), reused 582 (delta 145) #Receiving objects: 100% (2452/2452), 561.32 KiB | 438 KiB/s, done. #Resolving deltas: 100% (1238/1238), done. cd project.com git submodule init git submodule update #Cloning into vendor/plugins/project_engine... cd vendor/plugins/project_engine $ git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: public/javascripts/app/fckeditor/editor/skins/office2003/fck_dialog.css # modified: public/javascripts/app/fckeditor/editor/skins/office2003/fck_editor.css # modified: public/javascripts/app/fckeditor/editor/skins/silver/fck_dialog.css # modified: public/javascripts/app/fckeditor/editor/skins/silver/fck_editor.css # modified: public/javascripts/app/fckeditor/fckconfig.js # modified: public/javascripts/app/fckeditor/fckeditor.js # modified: public/javascripts/app/fckeditor/fckpackager.xml 

Lo único que parece eliminar los files es si inicio session como otro uso en mi Mac, lo que me hace pensar que es un problema mi máquina local y no el repository en sí.

También intenté desinstalar y volver a instalar GIT y actualmente estoy ejecutando la installation 1.7.5.4 y cumplí con la ayuda de brew (Ruby package manger).

¿Cómo elimino estos files del estado de git?

Estoy de acuerdo con Richard en que esto podría deberse a un problema de sensibilidad / insensibilidad de mayúsculas y minúsculas. Voy a abordar ese problema con esta respuesta.

Problema

Si un commit git contiene dos files cuyos nombres difieren solo en el caso, verificando que el commit a un directory de trabajo en un sistema de files insensible a mayúsculas / minúsculas cause problemas. Si la confirmación contiene, por ejemplo, myFILE y myFILE , git creará myfile y luego, cuando vaya a crear / actualizar myFILE , el sistema de files le da un manejador a myfile .

Esto se hace evidente si myfile y myFILE tienen diferentes contenidos en el repository. Al verificar los files, el segundo "gana" y el file físico contiene el contenido del segundo file. Cuando haces el git status , los dos files en el índice se comparan con el mismo file en el directory de trabajo, y para el file que pierde, el contenido no coincide.

Verificando el problema

Puede consultar el repository en un sistema sensible a mayúsculas y minúsculas para analizar y resolver todo lo que allí se encuentre. Alternativamente, git proporciona suficientes herramientas para lidiar con esto en su sistema actual.

La manera fácil de ver si este es realmente el problema es hacer una modificación trivial a uno de los files enumerados. Entonces, ejecutar el git status debería mostrar ambas variantes del nombre de file, ya que la versión del directory de trabajo no coincide con ninguna versión en el índice:

 $ echo >> public/javascripts/app/fckeditor/fckpackager.xml $ git status Possible outcome: # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: ... # modified: public/javascripts/app/fckeditor/fckpackager.xml # modified: public/javascripts/app/fckeditor/FCKPACKAGER.xml 

O bien, también puede usar git ls-files para ver lo que hay en el índice:

 $ git ls-files public/javascripts/app/fckeditor/fckpackager.xml public/javascripts/app/fckeditor/fckpackager.xml public/javascripts/app/fckeditor/FCKPACKAGER.xml 

Si desea ver exactamente qué hay en cada file, puede usar git checkout-index para extraer un file del índice y savelo en algún lugar (usando un prefijo para que los contenidos se escriban en files separados):

 $ git checkout-index --prefix=v1/ public/javascripts/app/fckeditor/fckpackager.xml $ git checkout-index --prefix=v2/ public/javascripts/app/fckeditor/FCKPACKAGER.xml 

Resolución

Una vez que haya descubierto qué variante de cada file desea eliminar, puede eliminarlo del índice utilizando git rm --cached , que respeta el caso de las routes dadas:

 $ git rm --cached public/javascripts/app/fckeditor/FCKPACKAGER.xml 

luego cometer, y si es necesario, hacer otro git reset --hard


Sin embargo, su comentario sobre el inicio de session como un usuario diferente y get resultados diferentes indica que podría haber un problema diferente. Siendo ese el caso, vería si hay diferencias en los files .gitconfig específicos del usuario.

Para limpiar un file sin seguimiento, debes usar

git clean -xdf

en lugar de

git clean -f only

-d Elimina directorys no rastreados además de files no rastreados. Si un directory no rastreado es administrado por un repository de git diferente, no se elimina de forma pnetworkingeterminada. Use la opción -f dos veces si realmente desea eliminar dicho directory.

-x No use las reglas de ignorar. Esto permite eliminar todos los files sin seguimiento, incluidos los productos de compilation. Esto se puede usar (posiblemente junto con el reinicio de git) para crear un directory de trabajo prístino para probar una compilation limpia.

Es posible que experimente un problema de sensibilidad a mayúsculas y minúsculas. Por defecto, los filesystems de Mac conservan las mayúsculas pero no distinguen entre mayúsculas y minúsculas.

Git mismo es sensible a mayúsculas y minúsculas. Si no tiene un sistema de files sensible a mayúsculas y hay dos files marcados cuyos nombres difieren solo por caso, el git status mostrará uno de los files modificado (suponiendo que el contenido de los dos files es diferente). Si tiene dos directorys cuyos nombres difieren solo por caso (por ejemplo, FCKeditor y FCKeditor ), entonces Git puede mostrar muchos files modificados.

Intenta crear un volumen sensible a mayúsculas y ejecuta git clone ahí.

Cambie al directory de submodules, es su propio repository, antes de realizar operaciones en ese repository de submodules. Debería poder limpiar y corregir el repository del submodule de la forma habitual.

Los diversos artículos del submodule (progit & git community book), si bien lo mencionan, no son tan claros como se necesitan para elegir ese punto.