Question

Ceci est lié à une autre question que j'ai posée récemment.

Lors de l’installation de msysgit, le programme d’installation présente 3 options relatives au chemin du système:

  1. Ne changez jamais l'environnement Windows. Avec cette option, vous devez utiliser la commande " bash " shell pour travailler avec git.

  2. Ajoutez le répertoire git \ bin à la variable d’environnement PATH, mais sans remplacer certains outils Windows intégrés. Fellow stackoverflow-ian Gabe Moothart m'a dit dans un commentaire que cette option ferait certaines opérations git échouent! Quelles sont ces opérations? Devrais-je m'inquiéter pour eux?

  3. Identique à 2 mais remplace certains outils système par défaut. Quels sont ces outils? Quelles parties des fenêtres en dépendent? et cela fera-t-il mal en pratique?

Un autre problème m’est venu à l’esprit, qui n’était pas lié au système PATH.

Que se passe-t-il si j'ai des liens symboliques et des liens physiques dans mon répertoire de projet? Git sait-il comment gérer ces problèmes? ou souffrira-t-il d'une récursion infinie, si, disons, la structure de répertoires était telle qu'un dossier était en fait un lien symbolique vers l'un de ses parents?

Était-ce utile?

La solution

Vous obtenez bash quelle que soit l'option sélectionnée, ces dernières options ne font qu'ajouter des méthodes d'utilisation de Git en dehors de celui-ci.

Pour les dernières options, msysgit ajoute les versions Windows des utilitaires Linux courants à CHEMIN . Ceci inclut find , kill et sort , ainsi que cp , ls , rm et environ 20 à 30 autres.

Le problème avec les 3 premiers (et similaires) est qu’ils existent dans les deux systèmes d’exploitation et fonctionnent différemment dans chacun d’eux.

Ce n'est pas une grosse épreuve si vous savez laquelle vous allez utiliser, mais toutes les applications développées qui en attendent une et qui obtiennent l'autre vont sûrement vous plaire.

Pour éviter le conflit, tout en maintenant le fonctionnement normal de Git, vous pouvez créer un script de traitement par lots simple qui ajuste PATH uniquement pour la session. (par exemple, readygit.bat )

@echo off
setlocal
set PATH=C:\Git\bin;%PATH%
cmd

Ajustez C: \ Git \ bin en conséquence. Mais, lancez simplement cela et utilisez Git dans cmd .

Grâce à cela, vous pouvez utiliser l'option d'installation 3 et supprimer en toute sécurité C: \ Git \ bin du PATH de votre système, en supprimant toute confusion pour les applications Windows sans créer de confusion pour Git.

J'utilise actuellement un script similaire avec les GnuWin , y compris < strong> rechercher .

Autres conseils

Vous voudrez peut-être savoir que:

  • Toutes les commandes git ne sont pas encore présentes. Sur MSysGit1.6.2 début mars 2009: archimport, cvsexportcommit, cvsimport, cvsserver, branche-filtre, instaweb, send-email et shell.)

  • Jusqu'à MSysGit1.6.2, git-svn était non il ( c'est maintenant ).
    Le problème était que git-svn avait besoin des liaisons Perl de subversion, et vous ne pouvez les construire que sous forme de modules chargeables dynamiquement. Et MSysGit avait une version Perl qui ne supportait pas les modules chargeables dynamiquement.

  • Tous les détails sur MSysGit sont mieux expliqués dans leur MSysGitHerald Wiki Github

Sous Windows (c’est moins un problème sur d’autres systèmes, à mon humble avis ...), vous devez être TRÈS au courant des problèmes de crlf et noter que (sauf s’ils l’ont changé dans la toute dernière version Je pense qu’ils ont peut-être un problème avec Git - ou si vous utilisez une version très ancienne de Git), autocrlf est activé par défaut, contrairement à toutes les autres installations de Git.

Notez également que, à moins que vous n'utilisiez la toute dernière version de msysgit, cette semaine, si je me souviens bien de la liste de diffusion, sera disponible cette semaine, la taille de votre référentiel ne pourra pas dépasser 2 Go.

De plus, Windows est étrangement insensible à la casse, mais parfois / dans le respect de la casse - gardez cela à l’esprit! (Cela ne confond pas nécessairement avec git - mais cela peut et doit confondre l'utilisateur du dépôt git).

Enfin, git est beaucoup plus lent sous Windows que sous Linux, bien qu’il soit (selon mon expérience limitée) plus rapide que les alternatives.

Maintenant, en ce qui concerne le chemin ...

Sauf erreur de ma part, vous devriez pouvoir vous assurer que le binaire principal de git est dans le chemin - et que ce binaire devrait ensuite s'occuper de référencer les autres composants de git ... Mais je n'ai pas testé cela.

Le programme d’installation MSYS Git propose l’option 2 si vous souhaitez exécuter git à partir d’une invite cygwin. L'environnement cygwin garantit que les dépendances git sont dans votre PATH. Si vous choisissez cette option mais appelez ensuite git à partir d'une invite de commande Windows, tous les utilitaires de ligne de commande unix-y sur lesquels git s'appuie ne seront pas trouvés. IIRC, git lui-même est partiellement implémenté en tant que scripts bash. Je ne sais pas quelles opérations vont échouer, mais je ne pense pas que git sera utilisable de cette façon.

Je n'ai pas de liste des outils système que l'option 3 remplace (le programme d'installation mentionne find.exe), mais cela ne vous concernerait que si vous êtes un ninja du traitement par lots. Sur la ligne de commande, find fera maintenant référence à l'utilitaire Unix de ce nom, et non à l'exe fourni avec Windows. Cela ne nuit en aucune façon à Windows.

Utilisez simplement des ciseaux et choisissez l'option 3: -)

Lorsque vous utilisez l'interface graphique Windows sur Windows et que vous créez votre tout premier référentiel, ne saisissez pas le nom " .git " pour le répertoire du référentiel. (Ce qu'il créera ensuite, puis créera un autre dossier .git en dessous, lorsque vous penserez enfin y jeter un coup d'œil). Naviguez jusqu'au dossier contenant vos sources et - choisissez ce dossier! Le répertoire du référentiel " .get " sera créé POUR VOUS.

Vous voyez ensuite les fichiers dans vos modifications non mises en scène et, en cliquant sur les petites icônes de page en regard des noms de fichiers, déplacez-les dans les modifications mises en scène.

Et exécutez définitivement avec des ciseaux et sélectionnez l'option 3. Plus personne n'utilise kill, sort ou find depuis la ligne de commande windows.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top