Diferenças entre atualização remota git e buscar?

Question

É git remote update o equivalente a git fetch?

Answer 1

UPDATE: Mais informações

Eu deveria ter feito isso desde o início: (! Tão meta) I grepped as notas de versão Git em Git repo do Git

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

Então eu fiz uma pesquisa less para --all, e é isso que eu encontrei sob o notas de versão para versão Git 1.6.6 :

opções

git fetch aprendeu --all e --multiple, a correr buscar de muitos repositórios, e opção --prune para remover monitoramento remoto ramos que foram obsoleto. Estes fazem git remote update e git remote prune menos necessário (não há nenhum plano para remote update remove nem remote prune, embora).

Versão 1.6.6 não foi liberado até dezembro 23 de 2009 , eo poster original fez sua pergunta em 06 de dezembro de 2009.

Então, como você pode ver as notas de lançamento, os autores do Git estavam cientes do fato de que a funcionalidade de comando git remote update estava sendo duplicado um pouco por git fetch, mas eles decidiram não removê-lo, talvez para compatibilidade com scripts existentes e programas, ou talvez porque é apenas muito trabalho e há itens de maior prioridade.

---

resposta Original com mais detalhes

resposta de xenoterracide é de 3,5 anos agora, e Git passou por várias versões, desde então, (que passou de v1.6.5.5 para v1.8.3.2 como esta escrito), e olhando para o atual documentação para git remote update e git fetch , parece que eles tanto pode executar basicamente a mesma função de buscar novos commits a partir de vários controles remotos , dadas as opções e argumentos certos.

Buscando todos os controles remotos

Uma maneira de buscar vários controles remotos é com a bandeira --all:

git fetch --all

Esta operação irá buscar de todos os seus controles remotos configurados, supondo que você não tem conjunto remote.<name>.skipFetchAll para eles:

Se for verdade, este controle remoto serão ignorados por padrão ao atualizar usando git-fetch (1) ou o subcomando atualização de documentação git-config

Isso seria equivalente a usar

git remote update

sem especificar qualquer grupo remoto para buscar, e também não ter set remotes.default na sua configuração de repo, e também que nenhum dos seus controles remotos têm conjunto remote.<name>.skipDefaultUpdate para true.

O atual 1.8.3.2 documentação para configuração do Git não menciona a configuração remotes.default, mas eu consultei o Todo-Poderoso Google sobre isso e encontrei este expl útilanation de Mislav Marohnic :

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

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

Você pode definir uma lista padrão de controles remotos de ser obtida pelo comando remote update. Estes podem ser controles remotos de seus companheiros de equipe, membros da comunidade de confiança de um projeto de código aberto, ou similar.

Assim, presumivelmente, se você tiver set remotes.default, e não todos os seus controles remotos estão listadas nele, então git remote update não vai buscar todos os controles remotos que o seu repo é "consciente" do.

Como para a configuração remote.<name>.skipDefaultUpdate, os docs Git explicá-lo assim:

Se for verdade, este controle remoto serão ignorados por padrão ao atualizar usando git-fetch (1) ou o subcomando atualização de git-remote (1) .

Buscando um grupo específico de controles remotos

Em vez de buscar todos os controles remotos, tanto fetch e remote update permitem especificar vários controles remotos e grupos de controles remotos para buscar:

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

git fetch [<options>] <group> permite buscar vários controles remotos que são parte de um grupo (para usar outro exemplo de Mislav ):

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

git fetch --multiple permite que você especifique vários repositórios e grupos de repositório para buscar de uma vez (a partir de os docs ):

Permitir vários argumentos <repository> e <group> a ser especificado. Sem <refspec>s pode ser especificado.

ambigüidade na documentação git remote update

O sinopse git remote update especifica que a sintaxe do comando é o seguinte:

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

Observe a última parte, [(<group> | <remote>)…]? A fuga pontos ... implica que você pode especificar vários grupos e controles remotos com o comando, o que significaria que ele se comporta da mesma maneira como git fetch --multiple ... ver como a sintaxe entre os dois é tão semelhantes?

No entanto, no mesmo documento, a explicação para o comando update não diz nada sobre como especificar múltiplos argumentos do grupo e remotos, só que ele

Fetch [es] atualizações para um conjunto nomeado de controles remotos no repositório conforme definido pela remotes.<group>.

Assim, não está claro se git remote update funciona de forma idêntica a git fetch --multiple em relação a especificar vários controles remotos individuais e múltiplos grupos remotos.

Buscando um único controle remoto

Finalmente, todo mundo sabe o caso simples de buscar um único controle remoto:

git fetch <remote>

Pode ser o caso que você também pode usar

git remote update <remote>

para fazer a mesma coisa, mas como eu mencionei na seção anterior, a documentação para git remote update não é clara sobre se é possível buscar outra coisa senão um único grupo de controles remotos com o comando.

Wrapup

Como eu expliquei, git fetch e git remote update comportamento semelhante em relação a buscar a partir de vários controles remotos. Eles compartilham sintaxe e argumentos semelhantes, embora git fetch é mais curto, de modopessoas provavelmente encontrá-lo mais fácil de digitar e usar.

Pode ser o caso que git remote update não pode ser usado para buscar apenas um único controle remoto como com git fetch, mas como eu já fora apontado, a documentação não deixar isso claro.

Além

A duplicação em funcionalidade entre os comandos de porcelana GIT, exemplificado por git fetch e git remote update acima, não é único. Tenho notado uma situação semelhante com git rebase --onto e git cherry-pick , em que tanto pode tomar uma variedade de commit remendo em uma nova base de cometer.

Eu acho que, como Git tem evoluído ao longo dos anos, algumas funcionalidades foi (inevitavelmente?) Duplicado, talvez, por vezes, como uma conveniência para os usuários finais (por exemplo, é mais simples para passar um intervalo para cherry-pick, do que passar um único cometer mais e mais para escolher um intervalo). Aparentemente cherry-pick nem sempre aceitar uma série de commits, como explicado na notas de lançamento v1.7.2 :

git cherry-pick aprendeu a escolher uma gama de commits (por exemplo cherry-pick A..B e cherry-pick --stdin), assim como git revert; estes não suportam o rebase [-i] controle de sequenciamento mais agradável tem, apesar de tudo.

Answer 2

Sim e não. fetches git remote update de todos os controles remotos, não apenas um.

Sem olhar para o código para ver se remote update é apenas um script shell (possível) que, basicamente, é executado buscar para cada remoto. git fetch pode ser muito mais granular.