Problema del flujo de trabajo de Subrepo en el cambio de Hg a Git

Nos encontramos con algunos problemas de flujo de trabajo en el cambio de hg a git (requisito comercial). En hg, solíamos restringir el acceso de los estudios tercerizados al código de propiedad creando subrepos con configuraciones de permissions específicos. Nuestros principales repositorys de hg tendrían sucursales que apuntaban a los subrepos Fuente o DLL apropiados para que pudieran cambiar fácilmente entre ellos.

El problema que nos encontramos es que imitar esta configuration en git parece imposible. Cambiar las twigs a una que no contenga un submodule específico no elimina los files de ese submodule localmente (comportamiento de git previsto). Esto crea un tedioso paso de eliminación manual que probablemente causaría problemas si lo extendiéramos a las personas less técnicas de la oficina. Necesitamos un sistema donde la gente pueda verificar la sugerencia de cualquier otro compromiso en la historia y se garantiza que tendrá un proyecto en funcionamiento, lo que no puede suceder si el contenido del submodule no se elimina en el sistema actual.

¿Hay alguna alternativa en lo que estamos tratando de hacer?

Puede usar un gancho de cliente post-checkout . Básicamente, cuando se cambian las sucursales a una que usa otro submodule, se ejecutará el enlace post-checkout . En este enlace, puede simplemente agregar código para eliminar todos los submodules que no sean utilizados por la twig actual.

Como los ganchos no se sincronizan entre los controles remotos y los repos locales, puede seguir esta sugerencia para get los enlaces a las personas que clonarán su repository.