Fichiers disparaissant entre pousser et tirer avec un repo nu au milieu

Question

J'ai donc un référentiel local avec deux branches: maître et boutique. J'ai également un référentiel nu et un référentiel distant. Je peux pousser et tirer bien entre tous ces éléments, mais il y a des fichiers qui ne cessent de se perdre. Je suis en train de faire ce qui suit:

De ma racine locale:

git push barereposerver shop 

Tout est bien. Whoo, nous avons poussé là. Et puis de la racine à distance, après avoir fait un git init et git ajouter à distance ssh nu: //blahblahblah/blah.git, je fais:

git pull bare shop 

Mais pour une raison quelconque, j'ai quelques fichiers qui ne sont pas rencontrés.

Je sais que je n'ai pas donné beaucoup d'informations, mais je suis très nouveau à git, et je ne connais pas encore la bonne terminologie. J'aimerais que vous me posiez quelques questions et que vous puissiez m'aider à traverser celle-ci. Merci beaucoup!

Mise à jour: une version latérale de ce que je cherche à faire. Je cherche à obtenir d'autres -> autre, par une prise en pension nue: http://droplr.com/wEB1q

Answer 1

À partir de votre diagramme, il ressemble à ce que vous avez fait est:

• poussée à nu (du local)
• puis, à partir à distance, inscrivez-vous repo nu, et tirer de nu

"de ma racine locale: git pousser bareserver boutique"

Ce qui est:

---

l'ensemble qui ne vient pas à travers sont un nouveau groupe de fichiers qui existent sur la branche locale, mais pour une raison quelconque, ne sont pas poussés à la branche à distance

Eh bien, tu as fait ajouter puis commit ces fichiers, avant d'essayer de pousser votre repo local? (Voir this question par exemple)

---

D'après les commentaires, voici comment nous avons suivi ensemble la cause profonde de ce problème:

Une autre façon de résoudre est de note la SHA1 du commit local (qui contient vos fichiers) et le SHA1 de ce que vous obtenez sur le côté distant (après avoir tiré de nu): si ce n'est pas la même chose, cela explique le contenu différent, mais vous pouvez également rechercher que SHA1 (obtenu sur la télécommande) sur le repo nu et sur le repo local, pour vérifier à quel commit SHA1 (qui manque de certains fichiers) se réfère.

Serait-ce ce numéro? 591178c18126be127eaa417fa6b3be86c0fce969 Si c'est le cas, je reçois le même numéro sur les sites distants et locaux.

Un SHA1 est en effet un tel nombre. S'il s'agit de la même chose sur le local et repo, le contenu doit être le même. Essayez (si vous n'avez aucune modification en cours sur remote) un git reset --hard (encore une fois, sur le repo distant); vérifiez d'abord que vous avez la CheckedOut branche directement dans votre repo à distance)

côte à côte, les deux résultats de git log:

et côte à côte, les deux dossiers avec des fichiers différents:

si le SHA1 est le même, alors les répertoires manquants ne devraient pas faire partie du commit locale.
Essayez de cloner votre dépôt local dans un deuxième dépôt local et vérifiez si vous voyez le même contenu dans les deux repos locaux.

Étrange. Lorsque j'ai cloné le dépôt local dans un autre dépôt local, les fichiers manquaient à nouveau. J'ai exécuté la commande clone à partir de la branche correcte. Des idées pour lesquelles cela serait?

C'est un côte à côté de l'ensemble des processus pour le clonage et l'affichage des résultats différents:

En ce moment, le fait que les répertoires sont manquants dans un clone local est une preuve suffisante que les les répertoires ne font pas partie des commits locaux de repo en premier lieu. Ces annuaires sont-ils vides? (Parce que même si elles sont ajoutées, ils ne seraient pas engagés)

Eh oui, ils sont totalement vide.
Ce sont des répertoires qui ont été créés à l'origine comme étant vides mais nécessaires pour qu'un greffon WP puisse écrire dans le but d'ajouter des choses.
Par ce SO question Je peux ajouter un .gitignore va essayer cela. Jusqu'à ce point, en deux semaines avec git, j'ai vu cela documenté nulle part. Cela semble être un gros problème à communiquer si rarement, ou est-ce que je rate quelque chose?

Ceci est en fait une décision de conception importante, une partie de ce qui fait Git un système de gestion de contenu de fichiers (voir Popularity of Git et Git versus SVN).

Ces répertoires, une fois ajoutés avec un .gitignore, sont maintenant poussés/tirés avec succès.