Eclipse + EGit : cloner le projet dans l'espace de travail

Question

Je ne comprends pas très bien le fonctionnement d'EGit.

J'ai un dépôt git existant sur Github et je veux le cloner dans mon espace de travail. Mon objectif est d'avoir le dépôt local directement stocké dans le dossier de mon espace de travail, mais je n'arrive pas à le faire fonctionner avec EGit.

Lorsque je veux cloner le repo github avec EGit, je dois choisir un répertoire comme destination. Le répertoire suggéré est dans mon homedir (pas dans mon espace de travail). Lorsque je choisis ce répertoire, je peux voir le projet dans Eclipse mais il n'est pas stocké dans le dossier de mon espace de travail. Au lieu de cela, il est stocké dans mon répertoire personnel.

Lorsque je choisis un répertoire directement dans mon espace de travail, plus tard, lorsqu'il s'agit d'importer le projet, il est indiqué qu'il existe déjà un répertoire portant ce nom.

Je ne sais pas comment résoudre ce problème. Je pensais que ce serait un scénario commun. Dans le passé, j'ai utilisé hgEclipse (Mercurial) et cela fonctionnait exactement comme je pensais que cela devait être, je suis donc confus qu'EGit ne le fasse pas. Peut-être ai-je mal compris quelque chose.

Il est probablement important de le savoir : Dans le dépôt github, il n'y a pas de fichiers .project ou .settings d'eclipse. Je les ai dans mon .gitignore et donc dans la boîte de dialogue d'importation je dois choisir "Importer comme projet général" et non "Importer des projets existants". Mais je pense que cela ne devrait pas avoir d'importance ?

J'espère que quelqu'un pourra m'aider ou m'expliquer pourquoi le plugin EGit ne clone pas le dépôt directement dans l'espace de travail par défaut.

Ma version d'Eclipse est 3.6, j'ai installé EGit sur la place de marché.

Answer 1

Comme mentionné dans ce Tutoriel EGit le répertoire de destination que vous mentionnez lors de l'importation (clonage) d'un repo Git est n'importe quel répertoire que vous voulez, dans lequel l'option .git sera créé :

Il n'est pas nécessaire de sélectionner l'espace de travail lui-même (du moins, vous devriez sélectionner l'espace de travail de l'entreprise). workspace/myproject afin de ne pas rendre le sous-répertoire todo Espace de travail Eclipse un repo Git.

Et vous pouvez sélectionner n'importe quel autre répertoire à l'extérieur de l'espace de travail : l'espace de travail Eclipse ne doit contenir que des méta-données sur les projets et les paramètres Eclipse.
Lors de la déclaration d'un nouveau projet, vous pourrez sélectionner le répertoire du projet, ce qui fera de ce répertoire le parent pour les éléments suivants .classpath y .project .
Votre espace de travail répertoriera ce nouveau projet, même s'il vit en dehors de l'espace de travail.

Answer 2

Pour importer un projet depuis GitHub, vous devez utiliser le dialogue Importer le dépôt Git comme nouveau projet ( clic droit -> Importation -> Git -> Dépôt Git comme nouveau projet ). De cette façon, vous pouvez sélectionner la destination du dépôt de clone, y compris l'espace de travail.

Answer 3

Si vous souhaitez modifier les sources dans l'IDE et que vous voulez également que les modifications soient reflétées dans le dépôt Git, supprimez le fichier source original dans le projet et liez le fichier source dans le dépôt git au projet. De cette façon, vous pouvez directement faire des changements dans le dépôt git et vous pouvez les commiter quand c'est nécessaire. Veillez toutefois à ne pas supprimer les fichiers lorsque vous supprimez le projet dans l'IDE.

Answer 4

Pourquoi ne pas simplement autoriser les deux possibilités.

Je suis d'accord pour le cas d'un grand projet qui génère de nombreux fichiers dans le dossier .metadata. Même s'il est assez simple de mettre la ligne .metadata dans le .gitignore afin d'améliorer les performances.

Mais dans mon cas (développement Android), j'ai environ 35 projets différents contenant seulement 50 fichiers.

Tous ces projets sont dans des worspaces différents contenant le projet d'application et les projets de bibliothèques pour cette application. (Un référentiel avec des sous-modules par application)

Dois-je avoir un seul espace de travail avec tous mes projets à l'intérieur (en perdant du temps à faire défiler/fermer/ouvrir les projets dans l'explorateur de paquets) ?

Dois-je gérer 2 dossiers de base différents (Projects et Worskspaces) avec le dernier contenant uniquement les dossiers .metadatas de tous mes projets ?

Pour moi, cela n'a pas de sens.

Message à l'équipe EGit :

Pourquoi changer la façon dont les développeurs organisent habituellement leurs dossiers de projets :

---- Projets

---- Projets / Application1 / .metada

-----Projets / Application1 / .git

-----Projets / Application1 / Application1Projet

-----Projets / Application1 / Bibliothèque1Projet

-----Projets / Application1 / Bibliothèque2Projet

---- Projets / Application2 / .metada

-----Projets / Application2 / .git

-----Projets / Application2 / Application2Projet

-----Projets / Application2 / Bibliothèque1Projet

Je comprends la raison de la performance mais pour seulement 5% des développeurs avec de très grands projets (générant de grandes métadonnées), vous ne nous permettez tout simplement pas de structurer nos projets comme Eclipse nous dit de le faire depuis des années.

Pourriez-vous juste, même si un message nous avertit que ce n'est pas recommandé, ne pas bloquer le processus de clonage vers le dossier worspace (" C:\Worspaces\ n'est pas un répertoire vide")

EGit est un excellent outil mais je pense vraiment utiliser la méthode Bash à cause de ce qui suit limitation.

Merci de votre réponse

PS : Il y a beaucoup de cas différents de développement sous Eclipse. Si c'est juste un problème de performance et que cela ne fait pas planter EGit, merci de nous en avertir mais ne nous bloquez pas dans le cas de petits projets.

Answer 5

Nope. Il n'y a aucun moyen de faire fonctionner ça. Vous ne pouvez pas utiliser egit pour extraire un projet git dans l'espace de travail et si vous l'extrayez ailleurs et essayez de le copier dans l'espace de travail, vous perdrez votre connexion au dépôt distant. Si vous voulez un VCS qui fonctionne, utilisez svn ou mercurial.