Git se niega a restablecer / descartar archivos

76

Tengo un proyecto con ciertos archivos js que no puedo actualizar. Ejecuto OSX localmente y mi servidor remoto / de ensayo es Linux (CentOS).

Inmediatamente después de clonar mi proyecto localmente, noté que tengo todos esos archivos con estado git modified. Nunca los modificados, así que he intentado discard changeso resetellos, pero vienen de nuevo. El cambio que está en la modificación es eliminar todas las líneas y agregarlas nuevamente.

No estoy seguro de por qué sucede esto o cómo solucionarlo para que mi estado de git esté limpio como debe ser.

Aquí hay algunas líneas del estado de git:

#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/el.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/fa.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/gu.js

ACTUALIZACIÓN 1:

Ahora he logrado enviar los archivos anteriores, pero el servidor de ensayo está bloqueado porque no generará nuevas ediciones:

error: Your local changes to the following files would be overwritten by merge:
    app/webroot/js/ckeditor/_source/lang/ar.js
    app/webroot/js/ckeditor/_source/lang/bg.js
    app/webroot/js/ckeditor/_source/lang/bn.js
    app/webroot/js/ckeditor/_source/lang/cs.js
    ...
Aborting

No puedo comprometerme / empujar porque:

Updates were rejected because a pushed branch tip is behind its remote counterpart

Lo intenté:

git reset --hard

y

git stash
git stash drop

Pero no funcionan, no pasa nada.

ACTUALIZACIÓN 2:

git diff me da:

The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/fa.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/gu.js.
The file will have its original line endings in your working directory.
...
git  git-status 
— mgPePe
fuente
Si los archivos se muestran modificados una y otra vez, verifique si existen diferencias como nueva línea, caracteres de control, etc. entre sus archivos locales y los archivos del repositorio.
— Shunya
No, no los hay. Habría mostrado solo 1 cambio de línea en comparación con todas las líneas. Además, si hubiera cambios reales, debería poder descartarlos, lo que no funciona en este caso.
— mgPePe
— Ohad Schneider

Respuestas:

105

Normalizar finales de línea

El cambio que está en la modificación es eliminar todas las líneas y agregarlas nuevamente.

Esto se debe a que se están cambiando las líneas nuevas entre los archivos confirmados y los archivos en el disco.

Github tiene una página útil que detalla cómo lidiar con este tipo de problema, en resumen (para linux / OSX), el primer paso es cambiar su configuración de git para que clasifique los finales de línea por usted:

git config --global core.autocrlf input

Luego confirma la normalización de los finales de línea:

git rm --cached -r .
# Remove everything from the index.

git reset --hard
# Write both the index and working directory from git's database.

git add .
# Prepare to make a commit by staging all the files that will get normalized.
# This is your chance to inspect which files were never normalized. You should
# get lots of messages like: "warning: CRLF will be replaced by LF in file."

git commit -m "Normalize line endings"
# Commit

Y luego, los finales de línea deben manejarse correctamente. Consulte la página de ayuda en github para obtener más información, o la sección relevante del formato y espacios en blanco de git docs .

Resolución de conflictos entre máquinas Linux

el servidor intermedio está bloqueado porque no generará nuevas ediciones.

El mensaje de error dice "Sus cambios locales en los siguientes archivos se sobrescribirán mediante la combinación:", eso significa que contienen cambios locales que deben confirmarse o descartarse antes de continuar. Suponiendo un uso normal para el servidor de ensayo (no tiene ningún cambio intencional), los cambios locales se pueden descartar. Por ejemplo, haga lo siguiente:

$ git fetch origin
# Retrieve updates

$ git reset --hard origin/master
# Forcibly change the current branch to match origin/master

Esto recuperará el historial del repositorio, sin actualizar la copia de trabajo, y luego se actualizará para que coincida exactamente con la rama maestra en el repositorio. Tenga en cuenta que el último comando descartará todos los cambios no confirmados.

— AD7six
fuente
¡Gracias! ¡Una respuesta tan completa, y te encargaste del conflicto de compromiso!
— mgPePe
1
Me acabas de salvar una tarde de dolor.
— Jerry Brady
Recibo un problema similar pero con imágenes. ¿Crees que estaría relacionado con esta respuesta?
— Will el
Tal vez, ¿cuál es la diferencia: finales de línea, ejecutables o algo más? Para cualquier respuesta más allá de "sí, eso fue todo" -> haga una pregunta que haga referencia a esta. La diferencia relevante, si hay una diferencia, es que los archivos de imagen son binarios y, por lo tanto, no deberían verse afectados por nada relacionado con el final de línea.
— AD7six
1
Tuvimos un equipo de contratistas bien intencionado que agregó los atributos .gitat con todas las normalizaciones de final de línea activadas. Esto causó confusión a los desarrolladores cuando no pudieron cambiar de rama porque esto corrompe el índice. Esta respuesta nos ayudó a borrar el caché y reconstruir el índice (git rm --cached -r. AND git reset --hard), pero la mejor solución para nosotros fue eliminar los atributos .gitat por completo para que todo funcionara como lo hacía antes lo cambió.
— neoscribe
15

Siempre mencioné que me aseguré de que tu core.autocrlfesté configurado en false, como en " Git: repo atascado usando alijo después de la normalización de crlf ".

git config --global core.autocrlf false

También asegúrese de no tener un .gitattributesarchivo con eoldirectivas que intenten convertir el final de las líneas.
La idea básica es: ¿sigue viendo ese mensaje de error cuando se asegura de que no haya conversión automática de ningún tipo?

Pero por si acaso, considere también " Git rebase falla, 'Sus cambios locales en los siguientes archivos se sobrescribirán mediante la combinación'. ¿No hay cambios locales? "

Estoy en una Mac, y este oscuro cambio de configuración pareció solucionar todos mis problemas con respecto a los cambios sin etapas cuando no había ninguno.

git config --global core.trustctime false
— VonC
fuente
2
buen consejo. Más apropiado si no hay ningún usuario de Windows colaborando para crear las nuevas líneas, o si los problemas son solo con los archivos del proveedor. Sin embargo, si no es un equipo mixto de ventanas + Mac / Linux usuarios - esto hará que los espacios en blanco perpetua cambia dependiendo de quién tocado el último archivo. +1.
— AD7six
1
Gracias por la información de .gitattributes . No lo sabía. En mi caso, esa fue la razón por la que no pude descartar los cambios. ¡Ahora problema resuelto!
— informatik01
1
El archivo .gitattributes con eol fue mi caso. ¡Gracias!
— JohnnyFun
10

Acabo de pasar 2 horas (!) En el mismo problema con un archivo .svg (Scalar Vector Graphics), que siguió cambiando después de 'revertir' sin mi intervención.

Entonces, el archivo aparece como modificado en 'git status' ; revertirlo tiene éxito, pero sigue cambiando, por lo que el 'tirón' falla una y otra vez ... ¡ qué molesto!

No tuve suerte con 'git reset' , 'git ignore' , 'git untrack', etc.

Finalmente, lo resolví eliminando el archivo de mi sistema local (no 'git delete' , solo Shift + Delete) >> ahora pasa la solicitud 'pull' , y el archivo se obtiene del repositorio remoto.

¡Tan fácil que podría llorar!

— Bar Naor
fuente
1
Enfoque alternativo interesante. +1
— VonC
Esta es la respuesta si está atascado porque revisa una confirmación anterior (lo que significa que no puede agregar una confirmación como se indica en la respuesta elegida)
— lulalala
1
Definitivamente es la solución más sencilla para mí. Gracias.
— nersoh
5

Este problema apareció repetidamente con el repositorio de hojas de caracteres Roll20 en una máquina Ubuntu y pude resolverlo 

#!/bin/sh

# Use in root dir of git repository
# Fixes some newline-related weirdness
git rm --cached -r .
git reset --hard

Pero, esto dejó de resolver el problema por completo hoy y al mirar alrededor de Stack Overflow encontré que el culpable era su .gitattributesarchivo:

# Auto detect text files and perform LF normalization
* text=auto

Después git pull origin master, git statusregresó:

On branch master
Your branch is up-to-date with 'origin/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:   Star Wars Revised RPG/SWRRPG-updated.html

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

La solución fue eliminar la * text=autolínea de .gitattributes:

$ git status
On branch master
Your branch is up-to-date with 'origin/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:   .gitattributes

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

Los cambios en .gitattributesse pueden descartar y Git seguirá estando satisfecho.

Editar + 1d : Intenté el "truco" de .gitattributes hoy, pero no git statusantes de descartar los cambios de .gitattributes. Sin ninguna razón obvia para mí (¿tal vez almacenando en caché git status?), git statusLuego devolvió esto nuevamente:

On branch master
Your branch is up-to-date with 'origin/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:   Star Wars Revised RPG/SWRRPG-updated.html

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

Haciéndolo de nuevo, pero con git statusintermedio funcionó.

— Kreuvf
fuente
Bien documentado. +1
— VonC
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.