origin - git remote

Recuperar compromiso específico de un repositorio remoto de Git

Question

¿Hay alguna manera de recuperar solo una confirmación específica de un repositorio remoto de Git sin clonarlo en mi PC? La estructura del repositorio remoto es absolutamente la misma que la mía y, por lo tanto, no habrá ningún conflicto, pero no tengo idea de cómo hacerlo y no quiero clonar ese enorme repositorio.

Soy nuevo en git, ¿hay alguna manera?

Answer 1

Con Git 2.5+ (Q2 2015), ¡realmente será posible obtener una única confirmación (sin clonar el repositorio completo)!

Ver commit 68ee628 por Fredrik Medley ( moroten ) , 21 de mayo de 2015.
^{(Fusionada por Junio ​​C Hamano - gitster - in commit a9d3493 , 01 de junio de 2015)}

Ahora tiene una nueva configuración (en el lado del servidor)

uploadpack.allowReachableSHA1InWant

Permitir que upload-pack acepte una solicitud de recuperación que solicite un objeto al que se pueda acceder desde cualquier consejo de referencia. Sin embargo, tenga en cuenta que el cálculo de la accesibilidad del objeto es computacionalmente costoso.
El valor predeterminado es false .

Con una combinación de clon superficial ( git fetch --depth=1 ), ahora puede solicitar una única confirmación (ver t/t5516-fetch-push.sh :

git fetch --depth=1 ../testrepo/.git $SHA1
git cat-file commit $SHA1

Se puede decir a " git upload-pack " que sirve " git fetch " que envíe confirmaciones que no están en la punta de ninguna referencia, siempre que sean accesibles desde un ref, con la variable de configuración uploadpack.allowReachableSHA1InWant .

La documentación completa es:

upload-pack : opcionalmente permite recuperar el sha1 alcanzable

Con la opción de configuración uploadpack.allowReachableSHA1InWant establecida en el lado del servidor, " git fetch " puede realizar una solicitud con una línea "want" que nombra un objeto que no ha sido anunciado (probablemente obtenido fuera de banda o desde un puntero de submódulo) .
Solo se procesarán los objetos accesibles desde las puntas de las ramas, es decir, la unión de las ramas anunciadas y las ramas ocultas por transfer.hideRefs .
Tenga en cuenta que hay un costo asociado de tener que retroceder en el historial para verificar la accesibilidad.

Esta característica se puede utilizar al obtener el contenido de una determinada confirmación, para la cual se conoce el sha1, sin la necesidad de clonar todo el repositorio, especialmente si se utiliza una búsqueda superficial .

Los casos útiles son, por ejemplo

• repositorios que contienen archivos grandes en la historia,
• buscando solo los datos necesarios para el pago de un submódulo,
• al compartir un sha1 sin decir a qué rama exacta pertenece y en Gerrit, si piensas en términos de commits en lugar de cambiar números.
  (El caso de Gerrit ya se ha resuelto mediante allowTipSHA1InWant ya que cada cambio de Gerrit tiene una referencia).

Git 2.6 (Q3 2015) mejorará ese modelo.
Ver commit 2bc31d1 , commit cc118a6 (28 de julio de 2015) por Jeff King ( peff ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 824a0be , 19 de agosto de 2015)}

refs : support negative transfer.hideRefs

Si oculta una jerarquía de refs utilizando la configuración de transfer.hideRefs , no hay forma de anular esa configuración para "mostrarla".
Este parche implementa una ocultación "negativa" que hace que las coincidencias se marquen inmediatamente como no ocultas, incluso si otra coincidencia la ocultara.
Nos ocupamos de aplicar las coincidencias en orden inverso de cómo nos las proporciona la maquinaria de configuración, ya que eso permite que nuestro habitual precedencia de configuración "último en ganar" funcione (y las entradas en .git/config , por ejemplo, anularán) /etc/gitconfig ).

Entonces ahora puedes hacer:

git config --system transfer.hideRefs refs/secret
git config transfer.hideRefs ''!refs/secret/not-so-secret''

para ocultar refs/secret en todos los repos, a excepción de un bit público en un repositorio específico.

Git 2.7 (noviembre / diciembre de 2015) mejorará nuevamente:

Consulte commit 948bfa2 , commit 00b293e (05 Nov 2015), commit 78a766a , commit 92cab49 , commit 92cab49 , commit 92cab49 (03 Nov 2015), commit 00b293e , commit 00b293e (05 Nov 2015), y commit 92cab49 , commit 92cab49 , commit 92cab49 , commit 92cab49 (03 Nov 2015) por Lukas Fleischer ( lfos ) .
Ayudado por: Eric Sunshine ( sunshineco ) .
^{(Combinado por Jeff King - peff - in commit dbba85e , 20 de noviembre de 2015)}

config.txt : documenta la semántica de hideRefs con espacios de nombres

En este momento, no hay una definición clara de cómo se debe comportar transfer.hideRefs cuando se establece un espacio de nombres.
Explique que los prefijos de hideRefs coinciden con los nombres eliminados en ese caso. Así es como los patrones hideRefs se manejan actualmente en el paquete de recepción.

hideRefs: agregue soporte para hacer coincidir referencias completas

Además de combinar hideRefs despojados, ahora se pueden agregar patrones hideRefs los que se hideRefs el ref completo (sin desvío).
Para distinguir entre las coincidencias completa y eliminada, los nuevos patrones deben ir precedidos de un circunflejo ( ^ ).

De ahí la nueva documentación :

transfer.hideRefs:

Si un espacio de nombres está en uso, el prefijo del espacio de nombres se elimina de cada referencia antes de que coincida con los patrones de transfer.hiderefs .
Por ejemplo, si se especifica refs/heads/master en transfer.hideRefs y el espacio de nombres actual es foo , entonces se omite refs/namespaces/foo/refs/heads/master en los anuncios, pero refs/heads/master y refs/namespaces/bar/refs/heads/master todavía se anuncian como líneas llamadas "tener".
Para hacer coincidir los refs antes de pelar, agregue un ^ delante del nombre de la referencia. Si combinas ! y ^ ! debe ser especificado primero.

Answer 2

Creo que ''git ls-remote'' ( http://git-scm.com/docs/git-ls-remote ) debería hacer lo que quieras. Sin forzar a buscar o tirar.

Answer 3

Finalmente encontré una forma de clonar la confirmación específica usando git cherry-pick . Asumiendo que no tienes ningún repositorio en local y estás tirando confirmación específica desde remoto,

1) crear un repositorio vacío en init local y git

2) git remote add origen " url-de-repositorio "

3) git fetch origen [esto no moverá sus archivos a su área de trabajo local a menos que se fusionen]

4) git cherry-pick " Enter-long-commit-hash-that-you-need "

Hecho. De esta manera, solo tendrá los archivos de esa confirmación específica en su localidad.

Enter-long-commit-hash:

Puedes obtenerlo usando -> git log --pretty = oneline

Answer 4

Hice un tirón en mi git repo:

git pull --rebase <repo> <branch>

Permitiendo que git ingrese todo el código de la rama y luego fui a hacer un reinicio a la confirmación que me interesaba.

git reset --hard <commit-hash>

Espero que esto ayude.

Answer 5

Simplemente puede recuperar el repositorio remoto con:

git fetch <repo>

dónde,

• <repo> puede ser un nombre de repositorio remoto (por ejemplo, origin ) o incluso una URL de repositorio remoto (por ejemplo, https://git.foo.com/myrepo.git )

por ejemplo:

git fetch https://git.foo.com/myrepo.git

Después de que haya obtenido los repos, puede fusionar los commit que desee (ya que la pregunta es sobre recuperar un commit, en su lugar se puede combinar cherry-pick para elegir solo un commit):

git merge <commit>

• <commit> puede ser el compromiso SHA1

por ejemplo:

git cherry-pick 0a071603d87e0b89738599c160583a19a6d95545

o

git merge 0a071603d87e0b89738599c160583a19a6d95545

si es la última confirmación que desea fusionar, también puede usar la variable FETCH_HEAD:

git cherry-pick (or merge) FETCH_HEAD

Answer 6

Simplemente puede recuperar una única confirmación de un repositorio remoto con

git fetch <repo> <commit>

dónde,

• <repo> puede ser un nombre de repositorio remoto (por ejemplo, origin ) o incluso una URL de repositorio remoto (por ejemplo, https://git.foo.com/myrepo.git )
• <commit> puede ser el compromiso SHA1

por ejemplo

git fetch https://git.foo.com/myrepo.git 0a071603d87e0b89738599c160583a19a6d95545

después de que haya obtenido la confirmación (y los antepasados ​​que faltan) simplemente puede realizar el pago con

git checkout FETCH_HEAD

Tenga en cuenta que esto lo llevará al estado de "cabeza separada".

Answer 7

Solo clona una vez, por lo que si ya tiene un clon del repositorio remoto, al extraerlo no se descargará todo nuevamente. Simplemente indique qué rama desea extraer, o busque los cambios y obtenga la confirmación que desea.

La obtención de un nuevo repositorio es muy económica en ancho de banda, ya que solo descargará los cambios que no tenga. Piense en términos de que Git está haciendo lo correcto, con una carga mínima.

Git almacena todo en la carpeta .git . Un compromiso no se puede recuperar y almacenar de forma aislada, necesita todos sus antepasados. Están interrelacionados .

Sin embargo, para reducir el tamaño de la descarga, puede solicitarle a git que busque solo los objetos relacionados con una rama específica o confirmar:

git fetch origin refs/heads/branch:refs/remotes/origin/branch

Esto descargará solo los commits contenidos en la rama de branch remota (y solo los que falte) , y lo almacenará en origin/branch . A continuación, puede fusionar o pagar.

También puede especificar solo una confirmación SHA1:

git fetch origin 96de5297df870:refs/remotes/origin/foo-commit

Esto descargará solo la confirmación del SHA-1 96de5297df870 especificado (y sus ancestros que se omite), y la almacenará como origin/foo-commit sucursal remota origin/foo-commit (no existente).