2016-12-02 6 views
0

Je travaille dans une grande entreprise où toutes les machines de développement sont Windows 7 Enterprise SP1. J'exécute un projet de migration majeur de RTC à git (aboutissant à quelque chose comme 1200 repos git). Il n'y a pas de serveurs Windows dans l'environnement de production, les environnements de construction ou de test - tout est Solaris ou RedHat. La solution sera déployée à ~ 200 développeurs.existe-t-il un émulateur d'unix "sûr" pour exécuter git sur Windows?

Il y a généralement une poussée pour utiliser plus d'outils de ligne de commande Unix et il y a quelques alternatives différentes sur Windows telles que: Cygwin, git-bash, cmder. J'ai évité d'exécuter une machine virtuelle Linux complète car cela introduit trop d'autres problèmes (la plupart des développeurs n'ont pas de droits d'administration locaux et le proxy internet est un problème constant, donc je ne veux pas faire de problème réseau avec NAT).

Je cours Cygwin (mintty 2.6.2) pour les 8 derniers mois et cela a fonctionné jusqu'à aujourd'hui où j'ai rencontré un problème très sérieux avec git (v2.8.3) où l'état git a rapporté un répertoire de travail propre même bien que plusieurs fichiers et dossiers aient été supprimés dans le repo. Ce n'est qu'après avoir recréé un dossier portant le même nom que l'un des dossiers supprimés que tous les fichiers supprimés apparaissent correctement avec l'état git. Je vais expliquer les symptômes et ce que je faisais, mais jusqu'à présent, je n'ai pas reproduit le problème. Mon soupçon est que le problème réside quelque part entre le système de fichiers Linux émulé et le système de fichiers Windows réel. Y a-t-il une différence dans la façon dont les différents émulateurs réalisent cela?

Le problème spécifique j'ai frappé eu ces symptômes:

côté client:

    git status
  1. a montré un répertoire de travail propre
  2. git log a montré 3 engage A, B et C (commettras C vérifié out)
  3. Le contenu du dépôt était un dossier contenant un fichier, 2 fichiers supplémentaires dans le dossier racine, plus le dossier .git avec le contenu
  4. git stash list était vide
  5. branche git -a rapports seul maître, la tête et l'origine/maître

côté serveur:

  1. L'origine contenait 13 dossiers supplémentaires, chacun avec un fichier
  2. l'origine également contenue engage A, B et C
  3. branche principale est présente uniquement

commettre un était le vide initial commettre Commit B était l'endroit où tous les contenus ont été ajoutés, 14 dossiers et 16 fichiers. La validation C était une autre validation vide

La validation A et la validation C ont toutes deux été créées à l'aide d'outils pour faciliter la migration.Il exécute deux commandes: "git init" et "git commit --allow-empty -m 'initial commmit'"

Je ne pouvais pas comprendre comment le statut git ne rapportait pas les fichiers supprimés (je me souviens de les avoir supprimés, mais a été quelques jours auparavant avec plusieurs ordinateurs hiberne, et probablement un redémarrage ou deux de reprendre mon travail)

Essayer de comprendre ce qui était arrivé, je l'ai fait:

  1. J'ai créé un nouveau fichier alors couru « git ajouter "," git commit "(créer D) et" git push ". La validation D est apparue sur le serveur avec le nouveau fichier. Les 13 dossiers et fichiers supplémentaires étaient toujours présents sur le serveur.
  2. J'ai couru « git pull », qui est revenu « déjà à jour »
  3. J'ai vérifié les changements pour tous les commits du côté client et côté serveur, et toutes diff était la même
  4. Je cloné une nouvelle copie du repo et le contenu correspondait au serveur avec les 13 fichiers et dossiers supplémentaires avec la validation supplémentaire D et le fichier supplémentaire
  5. J'ai ensuite recréé un dossier avec le même nom que l'un des dossiers supprimés et couru "git status" où enfin tous les fichiers et dossiers supprimés ont été correctement signalés.

Je ne peux pas expliquer cela autrement sauf pour un bogue sérieux qui rend tout simplement dangereux d'utiliser git dans Cygwin. J'espère que la communauté aura peut-être quelques conseils à me donner dans ce domaine et que cette formulation est assez claire pour que les mods ne signalent pas mon message.

Je ferai de mon mieux pour essayer de reproduire le problème et mettre à jour le problème avec plus d'informations quand j'en ai.

Modifier: Mise à jour 2016-12-08

Mes tentatives pour reproduire l'erreur ont été infructueuses. Si je le vois encore pendant mon travail, je vais mettre à jour ce problème.

+0

Pourquoi n'utilisez-vous pas le port natif [Git for Windows] (http://git-for-windows.github.io/)? Depuis quelque temps, son développement est même soutenu par les proptietors de Windows ™. Il vient avec 'MinTTY' et un port de' bash' pour ceux qui aiment avoir plus d'expérience "Unix-like". En même temps, cela fonctionne correctement dans la console Windows native. – kostix

+0

@kostix J'ai git pour windows installé mais mon git bash s'exécute dans une version plus ancienne de mintty (2.0.6) que dans cygwin. Ma principale raison de préférer cygwin est qu'il était plus facile d'installer d'autres outils comme tmux + vim. – philbert

Répondre

1

Je n'ai jamais vu un tel comportement avec Git sur Cygwin. Actuellement, j'utilise Git pour Windows depuis Cygwin et ça marche aussi très bien. J'avais l'habitude d'utiliser le Cygwin Git, mais j'avais l'impression qu'il est plus lent que Git pour Windows, comme je suis passé à Git pour Windows utilisé à partir de Cygwin et cela fonctionne très bien. Si vous mettez à jour les boîtes Windows vers Windows 10, vous pouvez également envisager une autre option, Windows Subsytem for Linux, qui est un environnement Linux virtuel basé sur Ubuntu développé par MS avec Canonical. Il est encore en train de devenir mature et pas encore pleinement utilisable à mon avis, mais là vous avez un environnement virutal Linux nativement supporté où vous pouvez utiliser apt-get et ainsi de suite.

1

Le problème que vous avez mentionné est vraiment inattendu, et je doute que Cygwin puisse le provoquer. Mais vous avez des options suivantes

  • git est livré avec bash git, qui prennent en charge toutes les principales commandes unix et il semble tout à fait comme shell unix. J'utilise la version 2.9 de git sur Windows 10 et emploie fortement la commande principale d'Unix comme grep, la trouvaille & de trouvaille, et elles fonctionnent toutes excellentes. Même il prend en charge vi mais je ne l'utilise pas

  • git est livré avec git CMD, et les mêmes commandes git fonctionneront sur l'invite de commande windows comme sur unix.Vous ne devriez pas avoir besoin d'un émulateur séparé avec ceci.

  • Bien que vous mentionnez que vous utilisez Windows 7, mais maintenant Windows 10 est livré avec un support natif pour Unix Bash

  • Vous pouvez utiliser GnuWin32 mais je doute que ce sera mieux que Cygwin

+0

Merci pour le conseil sur gnuwin32. J'ai réussi à google cette réponse utile aussi: http://stackoverflow.com/questions/10712550/difference-between-gnuwin32-and-cygwin – philbert