¿Diferencias entre actualización remota de git y recuperación?

¿ Es git remote updateel equivalente a git fetch?

Dec 07 '09 03:12 David

ACTUALIZACIÓN: ¡más información!

Debería haber hecho esto desde el principio: busqué las notas de la versión de Git en el repositorio de Git (¡qué meta!)

grep --color=always -R -C30 fetch Documentation/RelNotes/* | less

Luego hice una lessbúsqueda --ally esto es lo que encontré en las notas de la versión 1.6.6 de Git :

git fetchaprendido --ally --multipleopciones, para ejecutar la búsqueda desde muchos repositorios y --pruneopción para eliminar ramas de seguimiento remoto que quedaron obsoletas. Estos git remote updatelos hacen menos necesarios (aunque no git remote prunehay ningún plan para eliminarlos ).remote updateremote prune

La versión 1.6.6 no se lanzó hasta el 23 de diciembre de 2009 , y el póster original hizo su pregunta el 6 de diciembre de 2009.

Como puede ver en las notas de la versión, los autores de Git eran conscientes del hecho de que la git remote updatefuncionalidad del comando estaba siendo duplicada en cierta medida por git fetch, pero decidieron no eliminarla, tal vez por compatibilidad con scripts y programas existentes, o tal vez porque es demasiado trabajo y hay elementos de mayor prioridad.

Respuesta original con más detalles.

La respuesta de xenoterracide tiene ahora 3,5 años, y Git ha pasado por varias versiones desde entonces (ha pasado de v1.6.5.5 a v1.8.3.2 al momento de escribir este artículo), y al mirar la documentación actualgit remote update de y git fetch, parece como si ambos pudieran realizar básicamente la misma función de obtener nuevas confirmaciones desde múltiples controles remotos , dadas las opciones y argumentos correctos.

Obteniendo todos los controles remotos

Una forma de recuperar varios controles remotos es con la --allbandera:

git fetch --all

Esto se obtendrá de todos sus controles remotos configurados, suponiendo que no remote.<name>.skipFetchAlllos haya configurado:

Si es verdadero, este control remoto se omitirá de forma predeterminada al actualizar usando git-fetch(1) o el subcomando de actualización de git-remote(1) . - documentación de git-config

Esto equivaldría a utilizar

git remote update

sin especificar ningún grupo remoto para recuperar, y tampoco haberlo remotes.defaultconfigurado en la configuración de su repositorio, y también que ninguno de sus controles remotos se haya remote.<name>.skipDefaultUpdateconfigurado en verdadero.

La documentación actual 1.8.3.2 para la configuración de Git no menciona la remotes.defaultconfiguración, pero consulté a The Todopoderoso Google al respecto y encontré esta útil explicación de Mislav Marohnić :

$ git config remotes.default 'origin mislav staging'
$ git remote update

# fetches remotes "origin", "mislav", and "staging"

Puede definir una lista predeterminada de controles remotos que el comando recuperará remote update. Pueden ser controles remotos de sus compañeros de equipo, miembros confiables de la comunidad de un proyecto de código abierto o similares.

Entonces, presumiblemente, si lo ha remotes.defaultconfigurado y no todos sus controles remotos están enumerados en él, entonces git remote updateno recuperará todos los controles remotos que su repositorio "conoce".

En cuanto a la remote.<name>.skipDefaultUpdateconfiguración, los documentos de Git lo explican así:

Si es verdadero, este control remoto se omitirá de forma predeterminada al actualizar usando git-fetch(1) o el subcomando de actualización de git-remote(1) .

Obteniendo un grupo específico de controles remotos

En lugar de recuperar todos los controles remotos, ambos fetchy remote updatele permiten especificar múltiples controles remotos y grupos de controles remotos para recuperar:

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>le permite recuperar varios controles remotos que forman parte de un grupo (para tomar prestado otro ejemplo de Mislav ):

$ git config remotes.mygroup 'remote1 remote2 ...'
$ git fetch mygroup

git fetch --multiplele permite especificar varios repositorios y grupos de repositorios para recuperarlos a la vez (de los documentos ):

Permita que se especifiquen varios argumentos <repository>. <group>No <refspec>sse puede especificar.

Ambigüedad en git remote updatela documentación

La sinopsis degit remote update especifica que la sintaxis del comando es la siguiente:

git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

Observe la última parte, [(<group> | <remote>)…]? Los puntos finales ...implican que puedes especificar múltiples grupos y controles remotos con el comando, lo que significaría que se comporta de la misma manera que git fetch --multiple... ¿ves cómo la sintaxis entre los dos es tan similar?

Sin embargo, en el mismo documento, la explicación del updatecomando no dice nada acerca de especificar múltiples argumentos de grupo y remotos, solo que

Obtener actualizaciones para un conjunto con nombre de controles remotos en el repositorio según lo definido por remotes.<group>.

Por lo tanto, no está claro si git remote updatefunciona de manera idéntica git fetch --multiplecon respecto a la especificación de múltiples controles remotos individuales y múltiples grupos remotos.

Obteniendo un solo control remoto

Finalmente, todo el mundo conoce el sencillo caso de buscar un único mando a distancia:

git fetch <remote>

Podría darse el caso de que también puedas utilizar

git remote update <remote>

para hacer lo mismo, pero como mencioné en la sección anterior, la documentación git remote updateno aclara si es posible recuperar algo más que un solo grupo de controles remotos con el comando.

Envolver

Como he explicado, git fetchse git remote updatecomporta de manera similar con respecto a la recuperación desde varios controles remotos. Comparten una sintaxis y argumentos similares, aunque git fetchson más cortos, por lo que a las personas probablemente les resulte más fácil escribirlos y usarlos.

Puede darse el caso de que git remote updateno se pueda usar para recuperar un solo control remoto como con git fetch, pero como he señalado, la documentación no lo deja claro.

Aparte

La duplicación de funcionalidad entre los comandos de porcelana de Git, ejemplificada por git fetcharriba git remote update, no es única. He notado una situación similar con git rebase --ontoy git cherry-pick, en el sentido de que ambos pueden tomar una variedad de confirmaciones para parchear una nueva confirmación base.

Supongo que a medida que Git evolucionó a lo largo de los años, algunas funciones se duplicaron (¿inevitablemente?), tal vez a veces como una conveniencia para los usuarios finales (por ejemplo, es más sencillo pasar un rango a cherry-pick, que pasar una única confirmación una y otra vez). para elegir un rango). Aparentemente cherry-pickno siempre aceptó una variedad de confirmaciones, como se explica en las notas de la versión v1.7.2 :

git cherry-pickaprendió a elegir una variedad de confirmaciones (por ejemplo, cherry-pick A..By cherry-pick --stdin), y también lo hizo git revert; Sin embargo , estos no respaldan el mejor control de secuenciación rebase [-i]que tiene.

Jul 07 '2013 12:07