2011-08-07 19 views
6

Necesitaba eliminar algunos archivos Xcode de un repositorio antiguo que debería haber sido ignorado. Así que me encontré con el siguiente comando¿Por qué la opción cache en filter-branch elimina archivos del directorio de trabajo?

git filter-branch --index-filter 'git rm -f --cached --ignore-unmatch *mode1v3 *pbxuser' HEAD 

Mi entendimiento es que la adición de --cached no afectaría el directorio de trabajo actual, pero git borrado esos archivos que coinciden también. Afortunadamente, tuve una copia de seguridad (!) Pero tengo curiosidad sobre por qué hace esto, o estoy malentendiendo lo que --cached hace?

+0

algo no relacionado ----- afaik, no se puede usar comodín ('*') con '--index-filter' - al menos no sin comillas. El shell desplegado por 'git filter-branch' expandiría el comodín usando el árbol de trabajo. –

+0

¿Lo intentó sin el '-f'? – VonC

+0

Sí mismo resultado sin '-f' – martinjbaker

Respuesta

4

El culpable no es el comando git rm. Su opción --cached funciona de hecho como dices. Puedes probarlo fácilmente en un pequeño repo de git.

Aunque la página man no lo menciona, git filter-branch no parece conservar su área de trabajo. En realidad, el comando se niega a funcionar si su área de trabajo no está limpia, lo que ya es una indicación.

Pero incluso si los archivos se han ido del área de trabajo, no se han ido del repositorio. Simplemente ya no están en ningún compromiso alcanzable en su rama actual. Pero las sucursales de filtro de rama son referencias a su rama antes de volver a escribir en el espacio de nombre de referencia refs/original /.

Utilice el comando git show-ref para verlo.

Puede consultar la versión anterior para acceder a los archivos eliminados. Puede usar el comando git cat-file blob refs/original/refs/heads/master:foo para obtener el contenido del archivo sin pagar (use la referencia mostrada por show-ref, foo es el nombre del archivo deseado). Hay un montón de posibilidades

Puede utilizar gitk --all para navegar a través tanto de su reescrito y sus sucursales actuales y verá que nada realmente se ha ido.

1

El comportamiento de git-filter-branch puede sorprender, como ha descubierto, y no lo protegerá de las consecuencias involuntarias cuando lo ejecuta.

En su lugar, recomendaría usar el BFG Repo-Cleaner, una alternativa más simple y más rápida, específicamente diseñada para eliminar archivos del historial de Git. Una forma en que hace la vida más fácil aquí es que will not delete, or change in any way, archivos en su última confirmación.

debe seguir las usage instructions - pero la corona de perforación es sólo esto: descargar el BFG's jar (requiere Java 6 o superior) y ejecutar este comando:

$ java -jar bfg.jar --delete-files *{mode1v3,pbxuser} my-repo.git 

Cualquier archivo que coincida con esa expresión en su historia repositorio - que no está también en su última confirmación - se eliminará.A continuación, puede utilizar git gc para limpiar los datos muerta:

$ git gc --prune=now --aggressive 

El BFG es generalmente mucho más fácil de usar que git-filter-branch - las opciones se adaptan alrededor de estos dos casos de uso comunes:

  • Extracción loco archivos grandes
  • Extracción contraseñas, credenciales & otros datos privados

Descripción completa: Soy el autor de BFG Repo-Cleaner.

Cuestiones relacionadas