modificados - git push tag

El estado de git muestra modificaciones incluso con autocrlf=false (6)

Estoy experimentando los mismos problemas que en esta pregunta: el estado de git muestra modificaciones, git checkout - <archivo> no los elimina

Git sigue mostrando modificaciones en el directorio de trabajo, incluso con git config --global core.autocrlf false :

E:/_dev/github/Core [master +0 ~93 -0]> git config --get-all core.autocrlf false false

(Tenga en cuenta que incluso he establecido que la configuración del --system sea false )

¿Por qué parece que Git todavía está modificando mi final de líneas?

Intenta deshacerse de las modificaciones

Base

E:/_dev/github/Core [master +0 ~93 -0]> 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: tools/StatLight/StatLight.EULA.txt ... more changes ... no changes added to commit (use "git add" and/or "git commit -a")

git checkout -.

E:/_dev/github/Core [master +0 ~93 -0]> git checkout -- . E:/_dev/github/Core [master +0 ~93 -0]> 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: tools/StatLight/StatLight.EULA.txt ... more changes ... no changes added to commit (use "git add" and/or "git commit -a")

Ocasionalmente esto tendrá un efecto de una manera extraña:

E:/_dev/github/Core [master +0 ~628 -0]> git checkout -- . E:/_dev/github/Core [master +0 ~361 -0]> git checkout -- . E:/_dev/github/Core [master +0 ~93 -0]> git checkout -- . E:/_dev/github/Core [master +0 ~93 -0]> git checkout -- . E:/_dev/github/Core [master +0 ~93 -0]> git checkout -- .

git reset --hard

E:/_dev/github/Core [master +0 ~93 -0]> git reset --hard HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master E:/_dev/github/Core [master +0 ~93 -0]>

git add.; git stash; git stash drop

E:/_dev/github/Core [master +0 ~93 -0]> git add . ... warnings .... warning: CRLF will be replaced by LF in tools/StatLight/StatLight.EULA.txt. The file will have its original line endings in your working directory. E:/_dev/github/Core [master +0 ~93 -0]> git stash Saved working directory and index state WIP on master: 11a7f9a Merge pull request #8 from RemiBou/master HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master E:/_dev/github/Core [master +0 ~93 -0]> git stash drop Dropped refs/stash@{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7) E:/_dev/github/Core [master +0 ~93 -0]> git status ./tools/StatLight/StatLight.EULA.txt # 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: tools/StatLight/StatLight.EULA.txt # no changes added to commit (use "git add" and/or "git commit -a")

Aunque no sé qué está causando este extraño comportamiento, conozco una forma más de descartar los cambios que podrían funcionar.

¡Advertencia! Sea extremadamente cuidadoso y haga una copia de seguridad primero; esto puede ser altamente destructivo.

Si todos los datos que le interesan están comprometidos en el repositorio , simplemente puede eliminar todo en su directorio de trabajo (por supuesto, excepto el directorio oculto .git) y ejecutar git reset --hard HEAD para que git git reset --hard HEAD a crear el directorio de trabajo únicamente desde el repositorio datos.

Recuerde verificar cuidadosamente si no tiene datos importantes que no sean rastreados por git antes de hacer esto. No es suficiente comprobar el git status para ver si hay cambios no confirmados: recuerde que al eliminar todos los archivos del directorio de trabajo también se borrarán los archivos que usted indicó a git que ignoraran, y no se volverán a crear con el git reset --hard HEAD porque no están rastreado en absoluto.

Comprueba si no tienes un archivo .gitattributes

Como se mencionó en la sección "Efecto" de la página man de gitattributes , esos archivos también pueden tener un efecto sobre eol y la transformación automática:

text ^^^^^^

Este atributo habilita y controla la normalización al final de la línea.
Cuando un archivo de texto se normaliza, sus finales de línea se convierten a LF en el repositorio.
Para controlar qué estilo de terminación de línea se usa en el directorio de trabajo, use el atributo eol para un solo archivo y la variable de configuración core.eol para todos los archivos de texto.

También verifique su configuración para core.eol , como se menciona en " Cómo funcionan las conversiones de terminación de línea con git core.autocrlf entre diferentes sistemas operativos ".

El problema de "autocrlf" es un problema típico para el repositorio ~~cross~~ multiplataforma (es decir, el uso de un recurso compartido de samba con tortoisegit sobre un servidor en Linux)

Me di cuenta, que a veces (a menudo), es más un problema "chmod" que uno autocrlf: - las ventanas de estado de git muestran modificaciones pendientes - git status linux no muestra nada

"cambio de modo 100755 => 100644 config / packager.xml"

Verifique que sus archivos "estáticos" no sean + x, (y en este caso a tortoisegit no le gustará)

Este problema puede .gitattributes

Lea la documentación detenidamente, pero básicamente solo importa el autocrlf si el text no está configurado en .gitattributes :

Sin especificar
Si el atributo de texto no está especificado, git usa la variable de configuración core.autocrlf para determinar si el archivo debe convertirse.

Encuentre su archivo .gitattributes través de:

find <root-dir> -name .gitattributes

Y grep para text , eol o crlf para encontrar a su culpable y revisar según sea necesario.

Puede simplemente cambiar este archivo y revertir el cambio sin comprometerse el tiempo suficiente para resolver su problema.

Esto parece un error en msysgit de hecho. Como solución alternativa, intente crear un archivo .gitattributes que contenga

* -text

Esto le indicará a git que no realice conversiones de EOL en ningún archivo.

Estoy investigando el comportamiento extraño de core.autocrlf en MSysGit, y encontré que tenía:

[core] autocrlf = false safecrlf = true ignorecase = true eol = native

en el archivo de configuración global y SIN la configuración core.autocrlf en un repositorio copiado de otra PC (no clonado, solo copiado), la emisión de un comando de git status resulta en TODOS los archivos de texto marcados como modificados (sin gitattributes).

Pero si agrega una configuración de core.autocrlf local (repositorio) en true y luego emite un comando de git status , todos los cambios desaparecen y el repositorio vuelve a estar limpio .

PERO (y este es el comportamiento extraño) si elimina la configuración de core.autocrlf recién agregada del archivo de configuración del repositorio (volviendo así al estado inicial exacto), ¡ el comando de estado de git continúa sin informar cambios !

Dado que no se han realizado operaciones en el repositorio, solo cambiando una configuración, y volviendo al estado original, ha hecho el truco ...

Si esto no es un error, no puedo imaginar quién en el mundo puede llamar a esto un comportamiento "normal".