0
votes

Fichier non brisé après la réinitialisation GIT

J'ai un problème avec Git. Ça continue à me dire que j'ai un fichier inactivé.

même après git reset --hard ou git Ajouter --Toutes Il affiche toujours le fichier comme instantané.

J'utilise Android Studio4.0

 Entrez la description de l'image ici

P.s. essayé toutes les réponses ici et aucun d'entre eux n'a travaillé pour moi


9 commentaires

Très probablement, il a été commis avec différentes lettres moulées dans un système d'exploitation / FS qui distingue les différents noms de caisses. Et Windows ne le fait pas. Vérifiez-le sous Linux et voyez comment il devrait ressembler et s'il s'agit d'un seul fichier avec ce nom même (cas sensible).


Différentes lettres de boîtes sont une possibilité. Mais toute l'équipe utilise Windows OS. une idée de la manière de résoudre ce problème? Renommer le fichier le ferait?


Tout d'abord, il serait préférable de le diagnostiquer correctement: je vérifierais sous Linux pour cela.


Essayez de le faire sur Windows sans git bash mais avec cmd ...


@zerkms qu'est-ce que dois-je vérifier sur Linux?


@ Dan1st a essayé de le faire avec cmd comme administrateur ..same problème


@REMONSHEHATTA THE EXACT PLAIRE PLEIN (Tous les répertoires + Le fichier lui-même) Nom, plus si l'un des répertoires dans le chemin ou le fichier lui-même existe plusieurs fois (avec des cas différents).


Supprimez le fichier et restaurez-le de GIT?


Vous pouvez essayer de supprimer le contenu du référentiel et d'exécuter git reset --hard


3 Réponses :


-2
votes

Si vous souhaitez supprimer tous les fichiers non planifiés, essayez ceci:

git checkout -- .


1 commentaires

Cela ne fonctionne pas pour moi. De plus, c'était l'une des réponses dans le lien que j'ai posté



1
votes

Ceci est une sensibilité de cas dans le numéro de nom de fichier: Comme vous pouvez le constater une fois que le fichier incriminé est nommé ontime_user_presenter.kt code>, une fois qu'elle est nommée Ontime_user_presenter.kt code>. Cela signifie que, d'une manière ou d'une autre, une commission a été créée dans votre repo git où les deux noms coexistés. p>

Vous pouvez confirmer ce que GIT a stocké comme liste de fichier: p>

git mv <bad_capitalization> foo
git mv foo <good_capitalization>


0 commentaires

0
votes

Voici une autre solution possible pour le problème de l'insensibilité de casse (sous Windows).

Le problème est que Windows utilise des répertoires insensibles sur cas par défaut mais qui peut être modifié par répertoire. P>

donc, juste SENTILISEZ LE DISATIAIRES SENSIENNES SENSIBLE STRAND>. P>

Évidemment, vous devez décider si vous voulez un répertoire sensible à la casse ou non. Les programmes / scripts faits spécifiquement pour Windows ne peuvent plus travailler, car ils pourraient s'appuyer sur un système de fichiers sensible à la casse. (Voir les commentaires) p>

Si vous utilisez cette solution, assurez-vous que tout ce que vous utilisez dans ce répertoire continue de fonctionner. P>

Windows fournit un programme d'utilité pour les opérations du système de fichiers nommé fsutil code>. p>

Ouvrir cmd code>, CD code> dans le référentiel et exécute les éléments suivants: p> xxx pré >

voir Ce site pour plus de détails. p>

Si vous souhaitez restaurer le comportement par défaut (insensible à la casse), vous pouvez simplement exécuter: P>

fsutil file setCaseSensitiveInfo . disable


2 commentaires

Un mot d'avertissement: cela apporterait des modifications qui pourraient briser Autre logiciel .


par exemple: Si d'autres programmes s'attendent à ce que mydoc.docx , mydoc.docx et mydoc.docx ouvrira ou écrire sur le même document, bien, bien, ça ne serait plus.