2009-12-07 9 views
4

Donc, je peux importer depuis p4 en utilisant git-p4 sans aucun problème. Tout semble fonctionner, mais mes fichiers PNG (et peut-être d'autres) sont corrompus.git-p4 mange mes fichiers image

J'ai lu des informations sur gitattributes et les problèmes de fin de ligne, mais rien de ce que je fais ne semble changer le résultat final. Images brisées

Mon fichier attributs est: * .png

binaires

Toutes les idées? Si je comprends bien, git est supposé être assez intelligent pour comprendre qu'un png est un fichier binaire sans cette aide.

Est-ce quelque chose de particulier à faire avec la façon dont p4-git extrait les fichiers de Perforce?

Mise à jour: C'est sur Windows. J'ai oublié que ce serait important.

+0

Utilisez-vous Git sur Windows? –

+0

Oui, désolé. C'est Windows. –

+1

Diffusez les fichiers (attendus et réels).Cela aidera à déterminer s'il s'agit d'un problème de type cr/lf ou si quelque chose d'autre se passe. – jdigital

Répondre

6

Le format de fichier PNG est doté d'un en-tête spécialement conçu pour détecter les programmes qui mettent fin à la conversion et qui provoquent une erreur si ce n'est pas le cas. Les 8 octets d'un fichier PNG sont: 89 50 4E 47 0D 0A 1A 0A, choisis spécifiquement parce qu'ils contiennent le retour à la ligne Unix et le retour à la ligne de Windows - ainsi les programmes effectuant la conversion automatique invalideront automatiquement le PNG. PNG Signature rationale

Il semble donc que c'est effectivement le problème; et plutôt que de supposer que Git est le problème, essayez de regarder l'importation de Perforce. Soit Perforce effectue la traduction, soit il a été initialement archivé dans un état corrompu, et aucune quantité de clonage/mise à jour ne corrigera le problème d'origine.

+0

Je suis d'accord - et j'ai pris cette ligne de pensée la nuit dernière. J'ai creusé à travers la source git-p4 et docs pour voir comment il a extrait les fichiers de Perforce. Il s'avère que cela fait juste une impression p4 // chemin // vers // fichier # révision Donc, j'essaie cela sur les fichiers PNG et ils ont l'air bien. (De plus, les fichiers enregistrés ne sont pas nouveaux.) Mon estimation actuelle est que la façon dont le flux est lu et écrit dans le script Python cause des dégâts. (git-p4 est un script python). Mais, je ne vois aucun rapport de cela nulle part ailleurs. Ça me fait penser que c'est autre chose dans ma configuration. –

1

Il y a plusieurs couches d'abstraction (très) perméable ici.

Premièrement, il y a ce que le serveur perforce peut stocker les fichiers. Deuxièmement, le client perforce peut être mangling newlines. Troisièmement, le script python peut être mangling newlines (Improbable). Quatrièmement, git pourrait être mangling newlines. Maintenant, sur Windows, et seulement sur Windows, git modifiera automatiquement les nouvelles lignes par défaut. (99% de la communauté git semblent détester cette option par défaut, mais c'est apparemment la seule option par défaut sensée sur Windows). En conséquence, si vous avez des problèmes de retour à la ligne, je vous suggère de rechercher manuellement chaque couche et de spécifier exactement comment vous voulez traiter les nouvelles lignes. Je suggère de les rendre explicites, pas automatiques.

Je vous suggère d'examiner d'abord la configuration de git, car les paramètres par défaut de Windows sont très différents, et les valeurs par défaut de git diffèrent entre certaines versions et certaines versions. (ie, msysgit est différent de cygwin - git de cygwin a une autre couche de newline mangling - cygwin lui-même).

Profitez-en.

0

Assurez-vous que votre fichier PNG est défini sur le type "binaire" dans Perforce. J'ai juste eu ce problème avec un fichier binaire aléatoire étant défini sur un type "texte" dans Perforce. Je ne sais pas pourquoi Perforce avait dérivé ce fichier comme étant du texte, mais cela causait des problèmes avec la détection par git-p4 de ce qu'il fallait faire avec ce fichier.