È meglio mantenere il repository Git all'interno o all'esterno dell'area di lavoro di Eclipse?

Question

Sono un tipico utente di Eclipse/Subversion che inizia la migrazione a Git. Ho studiato i concetti di base di git e ho deciso di attenermi a un approccio di progetto per repository inizialmente per mantenere le cose semplici. Sto ancora avendo problemi, però, decidendo dove posizionare il repository per ogni progetto.

Ho passato molto tempo a rivedere le risposte a this question, sebbene ritenga che l'autore di tale domanda presupponesse che si possa usare Eclipse solo per gestire il repository se il repository si trova all'interno dell'area di lavoro di Eclipse, che è, certo, non è vero.

La cosa che mi ha colpito di più di questa domanda, però, era il fatto che tutte le risposte tranne una (compresa la risposta accettata) suggerivano di tenere il repository all'interno dell'area di lavoro di Eclipse, mentre solo una risposta indicava che il EGit User Guide consigliava esatto opposto.

Sembrerebbe, tuttavia, che ci siano diversi approcci implementati da Eclipse/EGit, alcuni dei quali sembrano contraddire le raccomandazioni di EGit.

Ad esempio, se si utilizza la Creazione guidata nuovo progetto per creare un nuovo progetto PHP da Git e il repository è remoto, Eclipse/EGit creerà felicemente una cartella di progetto nell'area di lavoro di Eclipse e inserirà il repository (.git) in la cartella del progetto. Questo è il risultato finale che effettivamente desidero, poiché mantiene tutto incapsulato all'interno dell'area di lavoro di Eclipse.

Tuttavia, se si utilizza la Creazione guidata nuovo progetto e si seleziona un repository Git locale, Eclipse/EGit non clonerà il repository come fa per gli archivi remoti. Invece usa la copia di lavoro di quel repository come ubicazione del progetto, crea il suo .project e altre meta-cose in quella posizione e crea anche una nuova (apparentemente inutile) cartella all'interno di quella copia funzionante con lo stesso nome del tuo progetto (così finisci con, ad esempio, ~/git/blah/blah). Se elimini quella cartella superflua, finisci con una struttura identica al primo esempio, l'unica differenza è che la cartella del progetto non è una sottocartella della tua cartella di lavoro Eclipse, è da qualche altra parte sul tuo file system (es. ~/git/blah). L'unica cosa positiva che questo approccio sembra avere è che aderisce alle raccomandazioni nella Guida dell'utente EGit, ma dal punto di vista tecnico, è difficile vedere come questo sia davvero così diverso dal primo esempio.

Data queste osservazioni sconcertanti, mi chiedo quale tipo di esperienze le persone hanno avuto utilizzando ciascuno di questi approcci e quali potrebbero essere le insidie ​​se si ignorano le raccomandazioni nella Guida dell'utente EGit.

Answer 1

Le implicazioni di entrambe le soluzioni sono elencate direttamente nella guida utente collegata. Posso dirvi che la parte

Ciò può portare a problemi di prestazioni

è purtroppo molto vero. Quindi, se hai una directory git con un numero enorme di file all'interno dell'area di lavoro, molte operazioni git inizieranno con una finestra di dialogo "contando oggetti ..." che blocca l'IDE perché analizza tutti i file nell'area di lavoro. Per i miei attuali 20000 file ciò significa attendere da 10 a 20 secondi per ogni commit, ogni switch, ...

Nelle attività del tempo libero, dove posso fortunatamente utilizzare l'altra alternativa (avendo la directory di lavoro git al di fuori dell'area di lavoro) tutto si sente molto meglio ed è divertente fondersi e cambiare.

Quindi, per progetti di grandi dimensioni, considerare la directory git al di fuori dell'area di lavoro come prima scelta.

Answer 2

sto facendo la stessa migrazione come il manifesto originale e hanno trovato un altro thread in cui gli stessi dubbi sono espressi su raccomandazione Egit: Should I store git repository in Home or Eclipse Workspace?

@JamesG Quindi questo è il layout?

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

Answer 3

Perché non solo consentire le 2 possibilità.

Sono OK per il caso di un grande progetto che genera molti file nella cartella .metadata. Anche se è piuttosto semplice inserire la riga .metadata nel file .gitignore per migliorare le prestazioni.

Ma nel mio caso (sviluppo Android), ho circa 35 progetti diversi contenenti solo 50 file.

Tutti questi progetti sono in diversi siti web contenenti il ​​progetto dell'applicazione ei progetti di libreria per questa app. (Un repository con moduli per applicazione)

• Devo avere un solo spazio di lavoro con tutti i miei progetti interne (passare il tempo a di scorrimento/chiudi progetti/aperti nel package explorer)?

• Devo gestire 2 diverse cartelle di base (Progetti e Worskspace) con l'ultima contenente solo le cartelle .metadatas di tutti i miei progetti?

Per me questo non ha senso.

messaggio alla squadra EGit:

Perché cambiare gli sviluppatori modo in cui di solito organizzare i loro progetti cartelle:

---- Worspace

---- Worspace/.metada

----- Worspace/.git

----- Worspace/Project1

----- Worspace/LibraryProject1

----- Worspace/LibraryProject2

capisco il motivo prestazioni, ma solo il 5% degli sviluppatori con molto grandi progetti (generando grande .metadata) basta non ci permettono di strutturare i nostri progetti come Eclipse ci dice di fare da anni.

Potrebbe solo, anche se un messaggio ci avverte che è non è raccomandato, non bloccare il processo di clonazione alla cartella worspace ("C: \ Worspaces \ non è una directory vuota")

EGit è un ottimo strumento, ma sto davvero pensando di utilizzare il modo Bash di questa limitazione .

Grazie per la risposta

PS: Ci sono molti casi differenti di sviluppo in Eclipse. Se si tratta solo di un problema di prestazioni e se non si verifica un arresto anomalo di EGit, è sufficiente segnalarcelo ma non bloccarci in caso di piccoli progetti.