Subrepo problema di flusso di lavoro nel passaggio da Hg a Git

Question

Stiamo riscontrando alcuni problemi di flusso di lavoro nel passaggio da hg a git (requisiti aziendali). In hg, eravamo soliti limitare l'accesso degli studios esterni al codice proprietario creando sottorepos con le impostazioni specifiche delle autorizzazioni. I nostri repository hg principali avrebbero quindi rami che puntavano ai subrepos di Source o DLL appropriati in modo che potessero essere facilmente scambiati.

Il problema che stiamo incontrando è che l'imitazione di questa configurazione in git sembra impossibile. Il passaggio di rami a uno che non contiene sottomoduli specifici non elimina i file di quel sottomodulo localmente (comportamento git previsto). Questo crea un noioso passo di cancellazione manuale che probabilmente causerebbe problemi se lo distribuissimo alle persone meno tecniche dell'ufficio. Abbiamo bisogno di un sistema in cui le persone possano controllare la mancia da qualsiasi altro commit nella cronologia e sono garantiti per avere un progetto funzionante, cosa che non può accadere se il contenuto del submodule non viene eliminato nel sistema corrente.

Ci sono alternative in git a quello che stiamo cercando di fare?

Answer 1

È possibile utilizzare un gancio lato client post-checkout. Fondamentalmente, quando si passa da una diramazione a un'altra che utilizza un altro sottomodulo, verrà eseguito il hook post-checkout. In questo hook, puoi semplicemente aggiungere codice per rimuovere tutti i sottomoduli che non sono usati dal ramo corrente.

Poiché i ganci non sono sincronizzati tra i telecomandi e i repository locali, è possibile seguire il suggerimento this per ottenere i ganci alle persone che cloneranno il repository.