remove - git tag best practices

Git mostrando archivos idénticos a los modificados

Question

Git me muestra que un archivo completo ha cambiado, cuando parece que no puedo entender los cambios. Esto es cygwin git, pero también sucede en msysgit

$ git --version
git version 2.1.1

$ diff <(git show HEAD:File.cs) <(cat File.cs)
// Shows no differences

$ diff <(git show HEAD:File.cs | xxd) <(xxd File.cs)
// Shows no differences

$ git diff
// shows the entire file has changed

$ git hash-object <(git show HEAD:File.cs)
7b3762473342a5b040835bfef9f6b45c109ba48b

$ git hash-object <(cat File.cs)
7b3762473342a5b040835bfef9f6b45c109ba48b

$ git hash-object File.cs
7b3762473342a5b040835bfef9f6b45c109ba48b

yo tengo

$ git config --get core.fileMode
false

y

$ git config --get core.autocrlf
true

Realmente no tengo idea de lo que está pasando, todo quiere que sean iguales, pero git quiere crear un compromiso diciendo que todo el contenido fue eliminado y recreado. ¿Alguien que sabe git plomería tiene alguna sugerencia? Todo lo que puedo pensar es que git show está eliminando / normalizando los finales de líneas impares.

ACTUALIZAR:

Estoy bastante seguro de que está sucediendo porque el proceso de desarrollo es así. Pago de git, rsync a dev machine, desarrollo, rsync de nuevo. Creo que rsync está jugando con los finales de línea algunos. Es simplemente extraño que los gits no informen sobre los finales de línea, y parece que se confunde realmente sobre qué diablos está pasando. Aunque difieren la representación binaria de los archivos parecen ser idénticos.

ACTUALIZACIÓN 2:

Así que esto es súper molesto, y siento que me he topado con un error en git.

Por ejemplo

$ git gc
$ git checkout -- .
$ git clean -fd
$ git status

> shows a heap of modified files

Estoy bastante seguro de que no debería mostrar cambios, no importa dónde se ejecute, pero obtengo una lista de 20 cosas extrañas :(

Answer 1

Esto puede ser causado por un archivo .gitattributes que indica que debe hacer la normalización de EOL pero el repositorio que contiene los finales de línea no normalizados.

La solución simple es eliminar la línea relevante de .gitattributes . Esto podría ser

* text=auto

o

*.cs text

Un ejemplo rápido de cómo esto podría suceder es el siguiente:

$ echo "Hello World" > example.txt
$ unix2dos example.txt #Make sure it uses CRLF
$ git add example.txt
$ git commit -m "commit 1"
$ #Instruct git that all .txt files should be normalized
$ echo ''*.txt text'' >> .gitattributes 
$ git add .gitattributes
$ git commit -m "commit 2"

Ahora el repositorio se encuentra en un estado extraño, porque .gitattributes reclama que el archivo debería normalizarse antes de agregarlo al índice, pero la versión actual confirmada no está normalizada.

Sin embargo, en este punto, el git status no se da cuenta de que, debido a que el archivo no ha cambiado de tamaño o tiempo desde que se agregó al índice, se considera que el índice está actualizado:

$ git status
On branch master
nothing to commit, working directory clean

Pero cualquier cosa que invalide el índice hará que git considere que el archivo está sucio:

$ touch example.txt
On branch master
Changes not staged for commit:

        modified:   example.txt

no changes added to commit (use "git add" and/or "git commit -a")

Y git reset --hard o cualquier otra acción para tratar de restablecer el archivo al estado en el que se supone que se encuentra no solucionará esto. Esto se debe a que no hay manera de agregar el archivo al índice en su estado actual como está en el repositorio, porque se le ha ordenado a git que normalice ese archivo, y esa normalización nunca puede producir el objeto como está confirmado actualmente.

Esta es la razón por la que la página de GITATTRIBUTES(1) man GITATTRIBUTES(1) recomienda invalidar explícitamente todo el índice al introducir la normalización de final de línea de esta manera:

$ echo "* text=auto" >>.gitattributes
$ rm .git/index     # Remove the index to force Git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

Lea la sección sobre "Conversión de fin de línea" en la página del manual de gitattributes para más detalles.

En lugar de ir con la solución rápida de simplemente eliminar esa línea de .gitattributes , es posible que desee mantener la línea que termina las reglas de normalización y seguir adelante y normalizarlas ahora. Básicamente, eso significa simplemente cometer los más de 20 cambios que no desaparecerán, pero puede hacerlo metódicamente siguiendo las instrucciones anteriores sobre la introducción de la normalización de final de línea (menos la edición de los .gitattributes ) y luego confiando en que no sucederá de nuevo, porque todos los archivos ahora están comprometidos con finales normalizados, y cualquier archivo futuro que agregue también se normalizará. Es preferencia personal, en su mayoría.