web-dev-qa-db-fra.com

Git refuse de réinitialiser / supprimer les fichiers

J'ai un projet avec certains fichiers js que je ne peux pas mettre à jour. J'exécute OSX localement et mon serveur distant/intermédiaire est Linux (CentOS).

Juste après avoir cloné mon projet localement, j'ai remarqué que j'avais tous ces fichiers avec le statut git modified. Je ne les ai jamais modifiés, j'ai donc essayé de discard changes ou reset eux, mais ils reviennent. Le changement qui est dans la modification supprime toutes les lignes et les ajoute à nouveau.

Je ne sais pas pourquoi cela se produit ou comment le corriger pour que mon statut git soit propre comme il se doit.

Voici quelques lignes du statut 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

MISE À JOUR 1:

J'ai maintenant réussi à valider les fichiers ci-dessus, mais le serveur de transfert est verrouillé car il ne tirera pas de nouvelles modifications:

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

Je ne peux pas valider/pousser car:

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

J'ai essayé:

git reset --hard

et

git stash
git stash drop

Mais ça ne marche pas, rien ne se passe.

MISE À JOUR 2:

git diff Donne moi:

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.
...
74
mgPePe

Normaliser les fins de ligne

Le changement qui est dans la modification supprime toutes les lignes et les ajoute à nouveau.

Cela est dû au fait que les sauts de ligne sont modifiés entre les fichiers validés et les fichiers sur le disque.

Github a une page pratique détaillant comment traiter ce type de problème, en bref (pour linux/OSX), la première étape consiste à modifier votre configuration git afin de trier les fins de ligne pour vous:

git config --global core.autocrlf input

Validez ensuite la normalisation des fins de ligne:

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

Et puis, les fins de ligne doivent être gérées correctement. Voir la page d'aide sur github pour plus d'informations, ou la section pertinente des git docs formatage et espaces blancs .

Résolution des conflits Linux-machine

le serveur intermédiaire est verrouillé car il n'effectuera pas de nouvelles modifications.

Le message d'erreur indique "Vos modifications locales aux fichiers suivants seraient écrasées par la fusion:", cela signifie qu'elles contiennent des modifications locales qui doivent être validées ou ignorées avant de continuer. En supposant une utilisation normale du serveur de transfert (il n'a pas de modifications intentionnelles), les modifications locales peuvent être ignorées. Par exemple, procédez comme suit:

$ git fetch Origin
# Retrieve updates

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

Cela récupérera l'historique du référentiel, sans mettre à jour la copie de travail, puis mettra à jour pour correspondre exactement à la branche principale du référentiel. Notez que la dernière commande supprimera toutes les modifications non validées.

104
AD7six

J'ai toujours mentionné m'assurer que votre core.autocrlf est défini sur false, comme dans " Git: dépôt bloqué en utilisant stash après la normalisation crlf? "

git config --global core.autocrlf false

Assurez-vous également que vous n'avez pas .gitattributes fichier avec les directives eol qui tenteront de convertir les fins de ligne.
L'idée de base est: voyez-vous toujours ce message d'erreur lorsque vous vous assurez qu'il n'y a pas de conversion automatique d'aucune sorte?


Mais juste au cas où, considérez également " Git rebase échoue, 'Vos modifications locales aux fichiers suivants seraient écrasées par la fusion'. Aucune modification locale? "

Je suis sur un Mac, et ce changement de configuration obscur a semblé résoudre tous mes problèmes concernant les changements non planifiés quand il n'y en avait pas.

git config --global core.trustctime false
14
VonC

Je viens de passer 2 heures (!) Sur le même problème avec un fichier .svg (Scalar Vector Graphics), qui ne cessait de changer après 'revert' sans mon intervention.

Ainsi, le fichier apparaît comme modifié dans 'git status'; le rétablir réussit, mais il continue de changer, donc le 'pull' échoue encore et encore .... tellement ennuyeux!

Pas de chance avec 'git reset', 'git ignore', 'git untrack' etc ...

Enfin, je l'ai résolu en supprimant le fichier de mon système local (pas 'git delete', juste Shift + Delete) >> maintenant 'pull' la demande passe, et le le fichier est récupéré à partir du référentiel distant.

Si facile, je pourrais pleurer!

9
Naor Bar

Ce problème est apparu à plusieurs reprises avec le référentiel de feuilles de caractères Roll20 sur une machine Ubuntu et je pouvais le résoudre en

#!/bin/sh

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

Mais, cela a cessé de résoudre le problème complètement aujourd'hui et en regardant autour de Stack Overflow, j'ai trouvé que le coupable était leur .gitattributes fichier:

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

Après git pull Origin master, git status revenu:

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 solution consistait à supprimer le * text=auto ligne des .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")

Les changements sur .gitattributes peut être supprimé et Git sera toujours satisfait.

Edit + 1d: A réessayé le "truc" .gitattributes aujourd'hui, mais n'a pas git status avant d'annuler les modifications .gitattributes. Pour aucune raison évidente pour moi (peut-être la mise en cache de git status?), une git status a ensuite renvoyé ceci à nouveau:

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")

Je recommence, mais avec git status entre-temps travaillé.

4
Kreuvf