oxygen - install eclipse git plugin

¿Es mejor mantener el repositorio de Git dentro o fuera del área de trabajo de Eclipse? (3)

Las implicaciones de ambas soluciones se enumeran directamente en la guía del usuario que ha vinculado. Puedo decirte que la parte

Esto puede ocasionar problemas de rendimiento

desafortunadamente es muy cierto Entonces, si tiene un directorio de git con una gran cantidad de archivos dentro de su área de trabajo, muchas operaciones de git comenzarán con un diálogo de "conteo de objetos ..." que bloquea su IDE porque escanea todos los archivos en el área de trabajo. Para mis archivos actuales de 20000, esto significa esperar entre 10 y 20 segundos por cada confirmación, cada cambio, ...

En actividades de tiempo libre, donde afortunadamente puedo usar la otra alternativa (tener el directorio de trabajo git fuera del área de trabajo) todo se siente mucho más ágil y es divertido fusionarse y cambiar.

Por lo tanto, si elige proyectos grandes, considere el directorio git fuera del área de trabajo como primera opción.

Soy un usuario típico de Eclipse / Subversion que comienza la migración a Git. Investigué los conceptos básicos de git y decidí atenerme a un enfoque de proyecto por repositorio inicialmente para mantener las cosas simples. Todavía estoy teniendo problemas, sin embargo, decidir dónde colocar el repositorio para cada proyecto.

Pasé mucho tiempo revisando las respuestas a esta pregunta , aunque creo que el autor de esa pregunta asumió que solo puede usar Eclipse para administrar el repositorio si el repositorio está ubicado dentro del área de trabajo de Eclipse, que es, por supuesto, no es verdad.

Sin embargo, lo que más me impresionó de esta pregunta fue el hecho de que todas las respuestas menos una (incluida la aceptada) sugerían mantener el repositorio dentro del espacio de trabajo de Eclipse, mientras que solo una respuesta indicaba que la Guía del usuario de EGit recomienda exactamente lo contrario .

Sin embargo, en la práctica parecería que hay una serie de enfoques implementados por Eclipse / EGit, algunos de los cuales parecen contradecir las recomendaciones de EGit.

Por ejemplo, si usa el Asistente de Nuevo Proyecto para crear un Nuevo Proyecto de PHP desde Git y el repositorio es remoto, Eclipse / EGit creará felizmente una carpeta de proyecto en el área de trabajo de Eclipse y colocará el repositorio (.git) en la carpeta del proyecto. Este es el resultado final que realmente quiero, ya que mantiene todo encapsulado dentro del espacio de trabajo de Eclipse.

Sin embargo, si utiliza el Asistente para nuevo proyecto y selecciona un repositorio de Git que sea local, Eclipse / EGit no clona el repositorio como lo hace para los repositorios remotos. En su lugar, utiliza la copia de trabajo de ese repositorio como ubicación del proyecto, crea su .project y otras meta cosas en esa ubicación y también crea una nueva carpeta (aparentemente innecesaria) dentro de esa copia de trabajo con el mismo nombre que su proyecto (para que termine arriba con, por ejemplo, ~/git/blah/blah ). Si elimina esa carpeta superflua, termina con una estructura idéntica al primer ejemplo, la única diferencia es que la carpeta del proyecto no es una subcarpeta de su carpeta de espacio de trabajo Eclipse, sino que está en otro lugar de su sistema de archivos (por ejemplo, . ~/git/blah ). Lo único positivo que parece tener este enfoque es que se adhiere a las recomendaciones de la Guía del usuario de EGit, pero desde una perspectiva técnica, es difícil ver cómo esto es realmente tan diferente al primer ejemplo.

Dadas estas observaciones desconcertantes, me pregunto qué tipo de experiencias han tenido las personas al utilizar cada uno de estos enfoques y cuáles podrían ser las dificultades si se ignoran las recomendaciones de la Guía del usuario de EGit.

¿Por qué no solo permite las 2 posibilidades?

Estoy bien para el caso de un gran proyecto que genera muchos archivos en la carpeta .metadata. Incluso si es bastante simple poner la línea .metadata en .gitignore para mejorar las actuaciones.

Pero en mi caso (desarrollo de Android), tengo alrededor de 35 proyectos diferentes que contienen solo 50 archivos.

Todos estos proyectos están en diferentes espacios de trabajo que contienen el proyecto de aplicación y los proyectos de bibliotecas para esta aplicación. (Un repositorio con submódulos por aplicación)

¿Debo tener solo un espacio de trabajo con todos mis proyectos internos (pasar tiempo para desplazar / cerrar / abrir proyectos en el explorador de paquetes)?
¿Debo administrar 2 carpetas base diferentes (Proyectos y Espacios de trabajo) y la última contiene solo las carpetas .metadatas de todos mis proyectos?

Para mí esto no tiene sentido.

Mensaje al equipo de EGit:

Por qué cambiar la forma en que los desarrolladores suelen organizar sus carpetas de proyectos:

---- Worspace

---- Worspace / .metada

----- Worspace / .git

----- Worspace / Project1

----- Worspace / LibraryProject1

----- Worspace / LibraryProject2

Entiendo la razón del rendimiento, pero para solo el 5% de los desarrolladores con proyectos muy grandes (que generan grandes .metadata) simplemente no nos permiten estructurar nuestros proyectos como Eclipse nos dice que hagamos desde hace años.

¿Podría simplemente, incluso si un mensaje nos advierte que no es recomendable, no bloquee el proceso de clonación en la carpeta del espacio de trabajo ("C: / Worspaces / no es un directorio vacío")

EGit es una gran herramienta pero realmente estoy pensando en usar el estilo Bash porque de esto
limitación.

Gracias por su respuesta

PD: hay muchos casos diferentes de desarrollo bajo Eclipse. Si solo se trata de un problema de rendimiento y no hace que EGit se cuelgue, por favor avísenos, pero no nos bloqueen en el caso de proyectos pequeños.

Estoy haciendo la misma migración que el póster original y he encontrado otro hilo en el que se expresan las mismas dudas sobre la recomendación de Egit: ¿Debería almacenar el repositorio de git en Home o Eclipse Workspace?

@JamesG ¿Así que este es tu diseño?

~/projectA/workspace/.metadata ~/projectA/workspace/subproj1/.project ~/projectA/workspace/subproj2/.project ~/projectA/subproj1/.git ~/projectA/subproj1/file1 ~/projectA/subproj2/.git ~/projectA/subproj1/file2