Posterior a de esta prolongada selección de datos hemos podido resolver este rompecabezas que presentan algunos usuarios. Te regalamos la respuesta y deseamos resultarte de gran apoyo.
Solución:
La diferencia es que al usar --mirror
, todos las referencias se copian como es. Esto significa todo: sucursales de seguimiento remoto, notas, refs/originals/* (copias de seguridad de filter-branch). El repositorio clonado lo tiene todo. También está configurado para que una actualización remota vuelva a recuperar todo desde el origen (sobrescribiendo las referencias copiadas). La idea es realmente reflejar el repositorio, tener una copia total, de modo que pueda, por ejemplo, alojar su repositorio central en varios lugares o hacer una copia de seguridad. Piense en simplemente copiar directamente el repositorio, excepto en una forma mucho más elegante de git.
La nueva documentación prácticamente dice todo esto:
--mirror
Configure un espejo del repositorio de origen. Esto implica
--bare
. Comparado con--bare
,--mirror
no solo asigna las ramas locales del origen a las ramas locales del destino, sino que también asigna todas las referencias (incluidas las sucursales remotas, las notas, etc.) y establece una configuración refspec de modo que todas estas referencias se sobrescriban con ungit remote update
en el repositorio de destino.
Mi respuesta original también notó las diferencias entre un clon simple y un clon normal (no simple): el clon no simple configura ramas de seguimiento remotas, solo crea una rama local para HEAD
mientras que el clon simple copia las ramas directamente.
Supongamos que el origen tiene algunas ramas (master (HEAD)
, next
, pu
y maint
), algunas etiquetas (v1
, v2
, v3
), algunas sucursales remotas (devA/master
, devB/master
), y algunas otras referencias (refs/foo/bar
, refs/foo/baz
que podrían ser notas, escondites, espacios de nombres de otros desarrolladores, quién sabe).
-
git clone origin-url
(no desnudo): Obtendrá todas las etiquetas copiadas, una sucursal localmaster (HEAD)
seguimiento de una sucursal remotaorigin/master
y sucursales remotasorigin/next
,origin/pu
yorigin/maint
. Las ramas de seguimiento están configuradas de modo que si hace algo comogit fetch origin
, se recuperarán como esperas. Cualquier sucursal remota (en el control remoto clonado) y otras referencias se ignoran por completo. -
git clone --bare origin-url
: Obtendrá todas las etiquetas copiadas, sucursales localesmaster (HEAD)
,next
,pu
ymaint
, no hay ramas de seguimiento remoto. Es decir, todas las ramas se copian tal como están, y se configuran de forma completamente independiente, sin esperar volver a buscarlas. Cualquier sucursal remota (en el control remoto clonado) y otras referencias se ignoran por completo. -
git clone --mirror origin-url
: Hasta la última de esas referencias se copiará tal cual. Obtendrás todas las etiquetas, sucursales localesmaster (HEAD)
,next
,pu
ymaint
sucursales remotasdevA/master
ydevB/master
otros árbitrosrefs/foo/bar
yrefs/foo/baz
. Todo está exactamente como estaba en el control remoto clonado. El seguimiento remoto está configurado para que, si ejecutagit remote update
todas las referencias se sobrescribirán desde el origen, como si acabara de eliminar el espejo y volver a clonarlo. Como dijeron originalmente los documentos, es un espejo. Se supone que es una copia funcionalmente idéntica, intercambiable con el original.
$ git clone --mirror $URL
es una abreviatura de
$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror=fetch origin $URL)
(Copiado directamente de aquí)
Cómo lo expresa la página de manual actual:
Comparado con
--bare
,--mirror
no solo asigna las ramas locales del origen a las ramas locales del destino, sino que también asigna todas las referencias (incluidas las sucursales remotas, las notas, etc.) y establece una configuración refspec de modo que todas estas referencias se sobrescriban con ungit remote update
en el repositorio de destino.
Mis pruebas con git-2.0.0 hoy indican que la opción –mirror no copia ganchos, el archivo de configuración, el archivo de descripción, el archivo de información/exclusión, y al menos en mi caso de prueba algunas referencias (que no No lo entiendo.) Yo no lo llamaría una “copia funcionalmente idéntica, intercambiable con el original”.
-bash-3.2$ git --version
git version 2.0.0
-bash-3.2$ git clone --mirror /git/hooks
Cloning into bare repository 'hooks.git'...
done.
-bash-3.2$ diff --brief -r /git/hooks.git hooks.git
Files /git/hooks.git/config and hooks.git/config differ
Files /git/hooks.git/description and hooks.git/description differ
...
Only in hooks.git/hooks: applypatch-msg.sample
...
Only in /git/hooks.git/hooks: post-receive
...
Files /git/hooks.git/info/exclude and hooks.git/info/exclude differ
...
Files /git/hooks.git/packed-refs and hooks.git/packed-refs differ
Only in /git/hooks.git/refs/heads: fake_branch
Only in /git/hooks.git/refs/heads: master
Only in /git/hooks.git/refs: meta
Sección de Reseñas y Valoraciones
Si te gustó nuestro trabajo, eres capaz de dejar una sección acerca de qué le añadirías a esta sección.