I progetti A e B utilizzano entrambi il progetto di libreria L:
Agiudicaredaciòchelepersonehannoscrittosudiessosulweb,gestirequestasituazionesembraessereunmalditesta:
Ci sono soluzioni là fuori che evitano difficoltà come:
• Perdere lavoro perché il VCS ha fatto qualcosa di inaspettato
• Il subrepo infernale si unisce
• Errori causati dal VCS che punta a una versione inaspettata del sottomodulo,
spesso peggiorato perché l'utente non si rendeva conto che era successo
Non c'è assolutamente alcun motivo per evitare git submodule ; funziona lontano meglio della maggior parte delle "soluzioni" alternative. Basta che lo script di costruzione asserisca (ma non modifichi; per risolvere il problema 1) che il sottomodulo sia presente e aggiornato (risolve il problema 3), e solo apporta modifiche al sottomodulo come proprio repo, not come se facesse parte del repository principale (risolve il problema 2). Lo ripeto: apporta solo modifiche al sottomodulo come proprio repository.
Inoltre, le versioni recenti di git forniscono git submodule update --remote per estrarre automaticamente l'ultima versione dal ramo che stai monitorando.
Supponendo che non stai ignorando completamente il comando git più importante di tutti i tempi, git status (il cui output è incluso anche nell'editor quando si esegue git commit ), non si avranno problemi.
Ovviamente, se stai usando un frontend GUI, probabilmente è una schifezza, ma è vero che stai usando i submoduli o meno.
Leggi altre domande sui tag git version-control mercurial dependency-management