Respuestas:
ACTUALIZACIÓN: más información!
Debería haber hecho esto desde el principio: agarré las notas de la versión de Git en el repositorio de Git's Git (¡así que meta!)
grep --color=always -R -C30 fetch Documentation/RelNotes/* | less
Luego lessbusqué --all, y esto es lo que encontré en las notas de la versión de Git 1.6.6 :
git fetchaprendió--ally--multipleopciones, para ejecutar la búsqueda desde muchos repositorios, y la--pruneopción de eliminar las ramas de seguimiento remoto que quedaron obsoletas. Estos hacengit remote updateygit remote prunemenos necesarios (no hay ningún plan para eliminarremote updateniremote prune, sin embargo).
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 se estaba duplicando git fetch, pero decidieron no eliminarla, tal vez por compatibilidad con versiones anteriores de scripts y programas, o tal vez porque es demasiado trabajo y hay elementos de mayor prioridad.
Respuesta original con más detalles.
La respuesta de xenoterracide es de 3,5 años de edad ahora, y Git ha pasado por varias versiones desde entonces (se ha pasado de v1.6.5.5 a v1.8.3.2 partir de este escrito), y mirando a la actual documentación git remote updatey git fetch, lo que parece como si ambos pudieran realizar básicamente la misma función de recuperar nuevas confirmaciones de múltiples controles remotos , dadas las opciones y argumentos correctos.
Una forma de recuperar múltiples controles remotos es con la --allbandera:
git fetch --all
Esto obtendrá de todos sus controles remotos configurados, suponiendo que no los haya remote.<name>.skipFetchAllconfigurado:
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 sería equivalente a usar
git remote update
sin especificar ningún grupo remoto para recuperar, y tampoco haber remotes.defaultestablecido en su configuración de repositorio, y tampoco que ninguno de sus controles remotos se haya remote.<name>.skipDefaultUpdateestablecido en verdadero.
La documentación actual 1.8.3.2 para la configuración de Git no menciona la remotes.defaultconfiguración, pero consulté al Almighty 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 debe obtener el
remote updatecomando. Estos pueden ser controles remotos de sus compañeros de equipo, miembros de la comunidad de confianza de un proyecto de código abierto o similar.
Entonces, presumiblemente, si ha remotes.defaultconfigurado, y no todos sus controles remotos están enumerados en él, entonces git remote updateno obtendrá todos los controles remotos de los que su repositorio esté "al tanto".
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) .
En lugar de ir a buscar todos los mandos a distancia, tanto fetchy remote updatele permiten especificar varios mandos a distancia y los grupos de mandos a distancia para acarrear:
git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]
git fetch [<options>] <group>le permite obtener múltiples 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 buscar a la vez (de los documentos ):
Se requieren varios
<repository>y<group>argumentos que se indicará posteriormente. No<refspec>sse puede especificar.
Ambigüedad en la git remote updatedocumentació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 puede especificar múltiples grupos y controles remotos con el comando, lo que significa que se comporta de la misma manera que git fetch --multiple... ¿ve 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 la especificación de múltiples grupos y argumentos remotos, solo que
Obtener actualizaciones para un conjunto de controles remotos con nombre 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.
Finalmente, todos conocen el simple caso de buscar un solo control remoto:
git fetch <remote>
Puede ser el caso de que también puedas usar
git remote update <remote>
hacer lo mismo, pero como mencioné en la sección anterior, la documentación para git remote updateno está clara sobre si es posible obtener algo más que un solo grupo de controles remotos con el comando.
Como he explicado, git fetchy se git remote updatecomportan de manera similar con respecto a la obtención de múltiples controles remotos. Comparten sintaxis y argumentos similares, aunque git fetches más corto, por lo que las personas probablemente encuentren más fácil escribir y usar.
Puede ser el caso que git remote updateno se puede utilizar para obtener un solo control remoto como git fetch, pero como he señalado, la documentación no lo aclara.
Aparte
La duplicación en la funcionalidad entre los comandos de porcelana de Git, ejemplificada por git fetchy por git remote updateencima, no es única. He notado una situación similar con git rebase --ontoy git cherry-pick, en que ambos pueden tomar una serie de confirmaciones para parchear en una nueva confirmación de base.
Supongo que a medida que Git ha evolucionado 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 simple pasar un rango cherry-pickque pasar una sola vez una y otra vez) para elegir un rango). Aparentemente cherry-pick, no siempre aceptaba una serie de confirmaciones, como se explica en las notas de la versión v1.7.2 :
git cherry-pickaprendió a elegir una serie de confirmaciones (por ejemplo,cherry-pick A..Bycherry-pick --stdin), también lo hizogit revert; sinrebase [-i]embargo, estos no son compatibles con el mejor control de secuenciación .
Si y no. git remote updaterecupera todos los controles remotos, no solo uno.
Sin mirar el código para ver si remote updatees solo un script de shell (posible), básicamente, ejecuta fetch para cada control remoto. git fetchPuede ser mucho más granular.
git remote update, consulte la página de manual de git-remote.
git remote no es un script de shell, pero se genera git fetchdurante a remote update.
git fetch opciones de comando para a git remote update?
git fetch --all
git rebasees comomvygit cherry-pickes comocp. El--ontointerruptor no cambia eso. ¡Puede obtener un efecto de copiagit rebasesolo si especifica valores SHA1, de lo contrario, su rama se moverá!