2017-09-28 2 views
0

J'ai des fichiers qui n'ont pas été modifiés, mais qui semblent être bloqués dans la zone de transfert.Les fichiers apparaissent dans les "fichiers non stockés", mais ne peuvent pas être mis en scène (icône de blocage rouge)

J'ai démarré un repo bitbucket à partir d'un projet existant et à partir de la ligne de commande j'ai effectué un $ git remote add origin https://[email protected]/username/myrepo.git dans mon dossier de projet local. Puis a fait et initialiser à partir de la ligne de commande ainsi $ git push -u origin master. J'ai ensuite chargé le projet dans l'EDI eclipse en utilisant la commande IDE File>Import Project From File System. Après avoir fait cela, j'ai trouvé que certains des fichiers de mon projet dans la zone de transit, mais n'ont pas été modifiés et cliqué sur eux dans gitkraken ont également indiqué qu'ils étaient inchangés (mais je ne pouvais pas trouver un moyen de supprimer à partir de la zone de fichiers non mis à jour). Essayer de mettre en scène ces fichiers fait clignoter l'icône de la main qui clique comme un symbole de blocage rouge et rien d'autre ne se passe.

J'ai essayé la mise en scène et pousser ces « fantôme change » manuellement dans le cli, et obtenir cette sortie:

➜ myproject git:(master) 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: .classpath 
     modified: .project 
     modified: some-query.sql 

no changes added to commit (use "git add" and/or "git commit -a") 
➜ myproject git:(master) git add .classpath .project some-query.sql 
➜ myproject git:(master) git commit .classpath .project some-query.sql 
... 
<some git commit text> 
... 
➜ myproject git:(master) git push -u origin master 
Password for 'https://[email protected]': 
.... 
<some git push success text> 
.... 

Cependant, ces fichiers apparaissent toujours dans la zone « fichiers Unstaged ».

Si quelqu'un a une idée de ce qui se passe ici, une contribution serait appréciée. Merci :)

+0

Je vois un 'git add' mais pas de' git commit'. – o11c

+0

Mises à jour la question pour montrer que la validation ne résout pas le problème des fichiers toujours * coincé * dans la zone de gitkraken UI "fichiers non statiques". – lampShadesDrifter

Répondre

0

Je crois que vous avez juste besoin de valider les fichiers.

git commit -m "adding .classpath, .project, and some-query.sql modifications" 

Regardez l'info sur la différence entre le répertoire de travail, l'index et la prise en pension (il y a une quatrième zone, appelée la planque, ainsi). Lorsque vous mettez en scène, vous ne faites que déplacer les fichiers et les modifications du répertoire de travail dans l'index. Pour réellement mettre ces changements dans votre repo, vous devez les valider, ce qui ne fera que valider les choses dans l'index, pas les changements seulement dans le répertoire de travail. Donc, au début, les changements étaient juste dans votre répertoire de travail. Après git add <files>, ils ont été mis en scène dans l'index, mais pas validés. Après git commit ou git commit -m "<message>" puis ils sont déplacés dans un nouveau commit dans votre repo local. C'est seulement à ce moment que le push fera n'importe quoi, parce que le push ne déplace que les commits (et les références) du repos local vers le repos distant, il ne touche pas le répertoire de travail ou l'index.

+0

Merci pour ce rappel. Dans tous les cas, même après validation, il y a toujours des fichiers dans la zone "fichiers non stockés" de l'interface utilisateur de gitkraken qui ne disparaissent pas et montrent que le fichier n'a pas de changement. Question mise à jour pour refléter les changements. – lampShadesDrifter

+0

@lampShadesDrifter Intéressant - il y a donc quelque chose que Git considère comme différent dans les fichiers de ses routines de comparaison, mais une fois qu'il est traduit dans la sortie diff, ces changements ne sont plus présents. Pourrait-il être un end-line Unix vs Windows ou quelque chose comme ça? Pouvez-vous stocker le fichier à partir d'une validation préalable, vérifier la validation en cours, puis faire un diff directement sur les 2 fichiers? Vous voudrez peut-être modifier le comportement de la ligne de fin (c'est-à-dire mettre le drapeau à toujours checkout avec unix, et commettre avec des lignes de fin unix), recommit 1 ou 2 fois et voir si ça disparaît. – LightCC

+0

Plus ou moins - besoin de comprendre ce que Git pense est différent dans le repo comparer à après qu'il est extrait dans le répertoire de travail. – LightCC