Git svn clone tira mal repository

Al convertir un proyecto JavaScript / Web de Subversion a Git, veo un problema, incluso cuando empiezo desde cero (el primer repository de Git siempre es malo).

El clon git svn funciona bien. De aquí en adelante, extraer un repository simple se ve bien, pero al tirar de un repository con el directory de trabajo desde el repository clonado original o cualquier repository desnudo posterior aparece el siguiente error:

Cloning into 'R:\WebClone2'... done. fatal: unable to read tree f86e35f1f083aa394cd0c28871cb5433fe9751da warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD' 

No veo esta combinación exacta de errores en SO. Lo que he hecho hasta ahora

  • git fsck no muestra problemas, incluso con --full .
  • El proyecto de Subversion tiene carpetas vacías. ¿Podría esto ser un problema? Agregar .gitkeep a las carpetas vacías en la versión clonada no repara los clones descendentes.
  • Cuando hago un git status , básicamente quiere eliminar todos los files y carpetas en el repository. Si me comprometo, todo se va.
  • Si en cambio hago un pago por git, ese repository se convierte en "bueno". Repos clonados de esta buena copy, sin embargo, muestran el mismo problema.

Estoy perdido. Gracias por tu ayuda.

Actualización: puse .gitkeep en las carpetas vacías en Subversion, y reconvirtí con git svn clone – el mismo problema.

Nunca pude profundizar en el problema exacto, pero encontré una solución:

El repository de origen está en una máquina separada, accesible a través de una unidad mapeada en la networking de Windows. Cuando hice el clon navegando a través del Explorador de Windows, el clon falló con el error anterior. Pero cuando utilicé Remote Desktop o inicié session en la máquina directamente con mi usuario de networking y contraseña, el clon funcionó bien.

Lo único que puedo concluir es que se trata de un problema de permissions de inicio de session de Windows / networking. Y parte de la búsqueda de los errores de informe también lo insinuó.

¡Espero que esto ayude a alguien en el futuro!

Actualización: alguien más en la oficina tenía el mismo problema al clonar un repository desde la unidad de networking a su propia estación de trabajo. Las testings mostraron que:

  • Todos los demás pudieron clonar el repository en sus propias máquinas
  • No pudo clonar con su inicio de session de Windows en la máquina de otra persona
  • Otros pudieron clonar en su máquina con sus inicios de session de Windows

Esto parece apoyar el hecho de que hay algún tipo de problema de permissions de Windows, en lugar de un repository corrupto u otro problema de Git.