Le problème: Parfois, mais pas à chaque fois, GIT supprime le répertoire code> statique code> d'un repo. Nous ne sommes pas sûrs de ce qui le déclenche, mais il semble se produire lors de la fusion entre les branches ou parfois même de vérifier les branches. Cela fait cela sans demander et mange des fichiers suivis.
L'arrière-plan: p>
git rm code> ed le répertoire code> statique code> à un moment donné dans le passé, ou le mettre dans .gitignore code>, mais pas récemment. Et la tête de notre branche de développement n'a pas statique code> dans .gitignore code> et comporte des fichiers dans statique code> suivi. Li>
- Cela se produit si rarement que nous ne savons pas si c'est quelque chose que nous faisons, ou un problème intermittent, un bug avec git ou un arbre corrompu li>
- It pourrait ne pas être em> lors de la fusion d'une autre branche dans
Développer code>. Mais les branches sont toujours em> ramifiées de développent code> et revenez dans développent code>. Mais nous ne sommes pas sûrs. Li>
-
Nous utilisons Git-Flow, mais le problème se produit lorsque vous utilisez également des commandes non git-flux, également. P> LI>
-
comme exemples de quand cela peut frapper: p>
1) Steve a eu une branche développée qui était propre (aucune modification de commettre ou de stade) et de stabilité. Il a coupé une nouvelle version avec Démarrage de la libération de flux Git | Terminer Code> et dans le processus (éventuellement la fusion de fond du maître à développer), l'ensemble / statique / arbre a été supprimé. P>
2) Steve a réparé la suppression en supprimant les modifications (pour définir essentiellement le fichier). Mais ensuite, Steve a simplement changé de maître pour développer et que le / statique / dirt a été zappé à nouveau (c'était avec la tour git) p>
3) Parfois, la fusionner à partir d'une branche de fonctionnalité à développer en tant que fusion provisoire peut le déclencher. Il semble que cela se produise le plus souvent lors de la coupe d'une nouvelle version, bien que p> li>
ul>
pourrait-il être lié à la manière dont nous réparons le zappage de la / la Dir? Quelle est la meilleure façon de réduire les choses en vrac-leltete qui ont été supprimées? Ni jeter des changements locaux ou une réinitialisation matérielle à la tête semble guérir les choses. Une boîte de rebas peut-elle nous aider? P>
Mise à jour forte> Nous venons de vivre à nouveau simplement avec un git Ajouter. Code> - Aucune branche en mutation, pas de fusion. Est-ce que cela aide le diagnostic du tout? P> Voici le contenu de Steve's .git / config: P>
.DS_Store
*.pyc
*.log
*.log.*
*.bak
*~
settings_local.py
/build/
/static_collected/*
/static/uploads/*
/static/theme_files/*
/static/picture/*
pip-log.txt
*.tmproj
*.dot
*.db
*.sublime-project
*.sublime-workspace
/docs/_*
3 Réponses :
Cela semblerait être git de décider de fusionner à une branche que a) a le dossier supprimé b) qu'il pense est plus récent que la succursale que vous fusionniez. Pourrait-il y avoir une machine qui a un type de date américain et celui qui a un type de date européen? Ou l'un de vos tests impliquent-ils la réinitialisation de la date de la machine?
je voudrais
a) Vérifiez les régions de toutes les machines incluses dans votre développement. b) Choisissez un point fixe dans votre développement, copiez les fichiers et créez un nouveau repositif et allez-y.
Très intéressant. Nous ne vérifions que sur deux machines, et ils sont tous deux du temps britannique. Le temps n'est jamais salué avec. Mais peut-être que le journal git est devenu corrompu d'une manière ou d'une autre, avec une date future? Nous envisageons de re-baser (si c'est le mot juste) le référentiel à un moment donné si la question devient trop de problème.
Git ne se soucie pas de la date de la paternité ou de la validation des dates de l'autorité de la nécessité de l'histoire, il ne se soucie que de commettre la filiation. Les mauvaises dates ne peuvent pas causer à des fonts d'une manière différente.
@CHARLESBAILEY - Toute suggestion alors? Je suis exclu. (FWIW Il n'y a pas de dates futures dans le journal)
@Je: sans accès à votre référentiel et à un cas de test complet, il est impossible de dire.
Ouais malheureusement ça pourrait être ça. Aucun cas de test car il arrive trop par intermittence pour pouvoir proposer une hypothèse. Espérait peut-être obtenir des conseils de vérification.
Git peut ne pas se soucier des dates de l'histoire, mais quand il s'agit de fusionner (récursif), il doit savoir quelle version est la version la plus pertinente. Vous pouvez essayer de télécharger une version eval de Smart Git - l'interface du journal est assez jolie et vous pouvez facilement voir les journaux des fichiers individuels et les modifications apportées - n'ont jamais examiné les dossiers complets avant toutefois
D'accord dames et des gents, j'ai des excuses publiques à faire. Git n'était pas à blâmer . Je laisserai cette question ici comme une leçon à d'autres personnes qui peuvent passer de la même manière.
Nous utilisions le backend Django-Storages (un «plugin» pour activer Django de stocker des fichiers sur Amazon S3 de manière transparente). Cela a un test appelé Nous exécutions nos tests, comme de bons citoyens, avant de vous enregistrer. La plupart du temps, nous n'avons couru que des tests pour notre code, mais nous avons parfois exécuté des tests pour l'ensemble du projet (y compris des plug-ins 3ème partie). Cela produisait le comportement dans la question. Parce que nous avons couru des tests et git les choses ensemble, il n'était pas facile de broder quelle commande faisait la suppression (et les fichiers supprimés ne sont apparus que lorsque nous avons exécuté alors problème résolu. Encore une fois, désolé pour la coulée des aspirations sur le bon nom de Git! hashpathstoragetest . La déchirure de ce test supprime Paramètres.Media_root , qui a été réglé sur ./ statique . C'est défectueux, à mon avis. Il n'a pas de fichiers de suppression de couverture commerciale qu'il n'a pas créé.
statut git ).
Avez-vous déposé un rapport de bogue pour Django-Storages? Vous devriez définitivement!
OK Alors cela vient d'arriver - j'ajoute une réponse séparée parce que c'est si stupide. Nous avons une repositionnelle pour nos scripts SQL et un nouveau développeur modifié accidentellement .gitignore à contenir * .SQL - inutile de dire que les changements ont cessé de se propager sur cette branche - et heureusement, il a été attrapé avant toute perte de temps de développement significatif. Cependant, il n'est pas incomparable que cela puisse produire les problèmes ci-dessus - vous avez donc vérifié vos fichiers de directive GIT? Si le dossier est ignoré (et .gitignore est là aussi - c'est-à-dire ignoré) il pourrait disparaître et réapparaître presque par la magie.
@sehe c'était seulement un commentaire qui passe! Je vais intégrer les informations supplémentaires dans la question. Et désolé, ce n'est pas un repo public.
@stevejalim @joe -
ok dommage que vous ne pouvez pas créer un lien vers un repo avec le problème. Je peruétrouver .git / -print0 | xargs -0 grep -w static etGit journal - statique / , en vous assurant que le répertoire n'est jamais techniquement vide. Les répertoires vides ne sont pas suivis par Git. De plus, je considérerais des départements rares ou des sous-modules à jouer des tours sur votre esprit.Au fait, vous pourrez peut-être «distiller» le problème réel en faisant
filtre-fil-branche pour supprimer les choses que vous ne voulez pas exposer. Cela vous aiderait sérieusement à obtenir une réponse si vous pouviez l'emballer dans un minuscule repo partagé. (Voir PROGIT.ORG/Book/ch9-7.html#removing_Objects )Merci SEHE - Je vais jeter un coup d'œil aux deux choses que vous suggérez plus tard. J'ai bien peur que nous fabriquons le public actuel, et je suis sceptique, que nous puissions la reproduire dans une infime répétée partagée, suggérez-vous de la préparation et de la suppression massive du repo principal, laissant quelques fichiers, laissant quelques fichiers?
Si le répertoire est supprimé dans une branche et non modifié dans une autre branche, elle sera supprimée pendant la fusion. Cela pourrait-il être la cause?
@knittl oui c'est ce que je pense peut-être. Mais les branches de fonctionnalités sont toujours désactivées
développent et sont toujours intégrées. Et le répertoire statique n'est jamais supprimé par les États-Unis.