git - tutorial - sourcetree login

La aplicación SourceTree dice cambios no confirmados incluso para el repositorio recién clonado, ¿qué podría estar mal?

Question

Un repositorio de git remoto solo se clona en un cuadro local utilizando Atlassian SourceTree . Incluso no se han modificado realmente los archivos en el árbol de trabajo, Atlassian enumera un grupo de archivos de inmediato en "Cambios no confirmados". Cada archivo muestra el mismo recuento de líneas como eliminado y agregado, y este recuento equivale a la cuenta total de líneas en el archivo. Esto de alguna manera daría una pista de que estamos alcanzando algún tipo de problema de terminación de línea.

Sin embargo, el .gitattribute del repositorio contiene

# Set default behaviour, in case users don''t have core.autocrlf set.
* text=auto

que según el artículo de GitHub Tratar con finales de línea debe hacer explícitamente core.autocrlf verdadero para el repositorio. Sin embargo, también ~/.gitconfig contiene autocrlf = true .

Si se intenta "revertir" los archivos modificados de nuevo a la confirmación anterior, no hay ningún efecto. Los mismos archivos todavía se ven como no confirmados.

El repositorio se ha clonado en varias ubicaciones y se ha asegurado de que no haya archivos en la misma ruta, para asegurarse de que SourceTree o git no recuerden archivos antiguos.

El repositorio está colaborado con Windows, Linux y cajas de OSX. Este problema aparece solo en OSX.

¿Qué podría estar todavía mal en la configuración de SourceTree / repository / git?

Actualización # 1, 20. abr 2013

Como todavía hay algo mal, aquí hay salidas parciales de git config --list .

Desde la consola SourceTree (OSX)

core.excludesfile=/Users/User/.gitignore_global
core.autocrlf=input
difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE"
difftool.sourcetree.path=
mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED"
mergetool.sourcetree.trustexitcode=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.autocrlf=true

Aquí está la salida correspondiente del lado de Windows:

core.symlinks=false
core.autocrlf=false
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
http.proxy=
core.autocrlf=true
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.eol=native
core.autocrlf=true

Y completo .gitattributes para el repositorio en cuestión

# Set default behaviour, in case users don''t have core.autocrlf set.
* text=auto
*.php text
*.twig text
*.js text
*.html text diff=html
*.css text
*.xml text
*.txt text
*.sh text eol=lf
console text
*.png binary
*.jpg binary
*.gif binary
*.ico binary
*.xslx binary

Answer 1

Acabo de toparme con este problema. Un clon nuevo extraería varios archivos que no solo no estaban comprometidos, sino que también tenía muchas líneas de código nuevo. git reflog no mostró nada, no era una confirmación real, por lo que un HEAD separado estaba fuera de cuestión.

Después de aproximadamente una hora de investigación encontramos la causa. Uno de nuestros desarrolladores de * nix había, muy probablemente, agregado erróneamente archivos a una carpeta que tenía el mismo nombre que el que se pretendía pero que tenía una capitalización diferente. * los entornos de nix pudieron manejar esta nueva carpeta fácilmente, pero Windows (debido a su naturaleza insensible a las mayúsculas y minúsculas) fusionó las dos carpetas.

Entonces, por ejemplo, si tiene dos carpetas, prueba y prueba, cada una con un archivo.txt dentro y esos dos archivos file.txt no son idénticos, entonces Windows realmente copiará / reemplazará uno de ellos (no estoy seguro de qué orden clona las carpetas en) por lo tanto, "cambia" el archivo y crea cambios no confirmados en "Prueba / archivo.txt" directamente después de una nueva instalación.

Ejemplo:

test/
--file.txt (with contents of "This is a commit")
Test/
--file.txt (with contents of "This is a commit with some changes")

Esto siempre mostrará nuevos cambios no confirmados que consisten en agregar las palabras "con algunos cambios" a Test / file.txt al clonar en una máquina Windows, mientras que las máquinas * nix no tendrán problemas.

Esto no necesariamente aborda el problema del PO, sino que se relaciona directamente con la pregunta en el título. Espero que eso ayude a alguien por ahí.

Answer 2

Agregué las siguientes líneas al archivo de configuración. La otra cosa que hice fue hacer clic en la casilla de verificación "Archivos en etapas" y luego desmarcarlo, y todo se actualizó por sí solo. Buena suerte.

text = auto
autocrlf = true

Answer 3

Normalmente esta línea en .gitattribute :

* text=auto

asegura automáticamente que todos los archivos que Git considera texto tendrán terminaciones de línea normalizadas (LF) en el repositorio, incluso cuando git config core.autocrlf se establezca en false (valor predeterminado). Por lo tanto, Git cambia automáticamente los archivos de acuerdo con estas reglas.

Entonces tienes las siguientes posibilidades:

• asume que los cambios de normalización son correctos (en la medida en que están hechos a los archivos de texto) y simplemente los comete, por ejemplo

  $ git diff
  $ git commit -m "Introduce end-of-line normalization" -a

• eliminar / deshabilitar la normalización automática del archivo .gitattribute y restablecer los archivos,

• eliminar el índice y volver a escanear los archivos, por ejemplo

  $ rm -v .git/index # Or: git rm --cached -r .
  $ git reset --hard # Rewrite the Git index. Or: git add -u

• alternativamente, haga lo que haga, intente con force ( -f ), por ejemplo, git pull origin -f , git checkout master -f , etc.,

• use git línea de comando en su lugar, ya que podría ser un problema con la aplicación SourceTree en sí misma.

Ver: tratar con terminaciones de línea en documentos de GitHub.

Answer 4

Soy uno de los desarrolladores de SourceTree (en realidad, desarrollo la versión para Mac del producto), así que espero poder ser de alguna ayuda.

Las máquinas con Windows convierten CRLF a LF cuando se comprometen y de LF a CRLF al momento de pagar. autocrlf se asegura de que todo esté LF dentro del repositorio. Sin embargo, la opción text = auto es la que nos interesa, como dice en los documentos :

Cuando el texto se establece en "automático", la ruta se marca para la normalización automática al final de la línea. Si git decide que el contenido es texto, sus finales de línea se normalizan a LF al registrarse.

Entonces, al verla, verá "Oye, necesito normalizar estos finales de línea porque no están en formato LF, sino en CRLF". y así modifica su copia de trabajo para hacer el trabajo que se espera que haga. Por lo general, en Mac / Linux no necesitarías normalizar porque todo está en LF, pero Git hará una comprobación porque es posible que hayas salido de un repositorio que se desarrolló previamente en Windows, o quizás en un editor que estaba usando CRLF en lugar de LF

En resumen, es probable que desee volver a confirmar todos esos archivos como deberían estar en formato LF, pero también asegúrese de que autocrlf = true (edit, always to true!) En su repositorio de Windows como se dice en los documentos :

Si simplemente desea tener terminaciones de línea CRLF en su directorio de trabajo, independientemente del repositorio con el que esté trabajando, puede establecer la variable de configuración "core.autocrlf" sin cambiar ningún atributo.

Aunque imagine que la cita anterior fue cuando se configura autocrlf para un repositorio específico, así como a nivel mundial.

Espero que sea de alguna ayuda, si no, ¡siéntase libre de hacer más preguntas!

Aquí hay un buen SO post re: terminaciones de línea: ¿Por qué debería usar core.autocrlf = true en Git?

EDITAR

En base a la respuesta anterior, necesitamos asegurarnos de algunas cosas aquí.

• Que ha establecido las opciones relevantes de git en su .git/config
• Si desea mantener las terminaciones de línea CRLF, configure autocrlf=true
• Si, cuando revisa su repositorio, no quiere que sus terminaciones de línea se conviertan automáticamente (haciendo que todos sus archivos estén en el estado "modificado" inmediatamente) entonces configure la opción de text para unset . Agregue esta opción si una configuración de git global lo tiene configurado en un valor que no desea.
• Si está trabajando tanto en Windows como en Mac para un proyecto, lo mejor es que tenga text=auto y asegúrese de que se use LF en todos los ámbitos. Esta es la razón por la cual los problemas como este se arrastran; porque las configuraciones de tu git son diferentes o porque la configuración inicial del proyecto / git en Windows asume CRLF cuando tu Mac asume LF.

Answer 5

Todavía no lo entiendo al 100%, pero para nosotros el problema era el * text=auto en el archivo .gitattribute en el repositorio. Comprobé, y estamos seguros de que core.autocrlf=true configuró en todos los lugares para mi usuario en una PC con Windows. Sabía que no era un problema de SourceTree, ya que TortoiseGit y solo Windows Git (msysgit) tenían el mismo "problema" para este repositorio. Comportamiento realmente extraño: clonaría el repositorio una vez e inmediatamente vería 11 archivos "diferentes", luego eliminaría y volvería a comenzar y el próximo clon tendría 14 archivos "diferentes".

Al comentar el * text=auto en el archivo .gitattribute del repositorio, se corrigió todo. Es casi como text=auto no se comporta igual que autocrlf=true y este último está deshabilitado si el primero se establece en el archivo .gitattribute . Pero eso no es lo que parece indicar cada guía en línea.