“git fetch --tags” inclui “git fetch”?

Question

Uma pergunta simples e agradável - a função de "git fetch" é um subconjunto estrito de git fetch --tags?

Ou sejase eu correr git fetch --tags, existe algum motivo para executar imediatamente git fetch logo depois?

A respeito git pull e git pull --tags?Mesma situação?

Answer 1

Observação:começando com git 1.9/2.0 (primeiro trimestre de 2014), git fetch --tags busca tags além de o que é obtido pela mesma linha de comando sem a opção.

Ver cometer c5a84e9 por Michael Haggerty (mhagger):

Anteriormente, fetch's "--tags"opção foi considerada equivalente a especificar o refspec

refs/tags/*:refs/tags/*

na linha de comando;em particular, causou a remote.<name>.refspec configuração a ser ignorada.

Mas não é muito útil buscar tags sem também buscar outras referências, ao passo que é bastante útil para poder buscar tags além de Outras referências.
Portanto, mude a semântica desta opção para fazer a última.

Se um usuário quiser buscar apenas tags, então ainda é possível especificar um refspec explícito:

git fetch <remote> 'refs/tags/*:refs/tags/*'

Observe que a documentação anterior a 1.8.0.3 era ambígua sobre este aspecto de "fetch --tags" comportamento.
Confirmar f0cb2f1 (2012-12-14) fetch --tags fez com que a documentação correspondesse ao comportamento antigo.
Este commit altera a documentação para corresponder ao novo comportamento (veja Documentation/fetch-options.txt).

Solicite que todas as tags sejam obtidas do controle remoto além de tudo o mais que está sendo buscado.

---

Desde o Git 2.5 (2º trimestre de 2015) git pull --tags é mais robusto:

Ver cometer 19d122b por Paulo Tan (pyokagan), 13 de maio de 2015.
^{(Mesclado por Júnio C Hamano-- gitster -- em cometer cc77b99, 22 de maio de 2015)}

pull:remover --tags erro em caso de não mesclar candidatos

Desde 441ed41 ("git pull --tags":Erro com uma mensagem melhor., 2007-12-28, Git 1.5.4+), git pull --tags imprimiria uma mensagem de erro diferente se git-fetch não retornou nenhum candidato a mesclagem:

It doesn't make sense to pull all tags; you probably meant:
       git fetch --tags

Isto porque naquela época, git-fetch --tags substituiria qualquer refSpecs configurado e, portanto, não haveria candidatos de mesclagem.A mensagem de erro foi assim introduzida para evitar confusão.

No entanto, desde c5a84e9 (fetch --tags:buscar tags além deoutras coisas, 30/10/2013, Git 1.9.0+), git fetch --tags buscariam tags, além de qualquer refSpecs configurado.
Portanto, se ocorrer alguma situação de não mesclagem de candidatos, não é porque --tags foi configurado.Como tal, esta mensagem de erro especial é agora irrelevante.

Para evitar confusão, remova esta mensagem de erro.

---

Com Git 2.11+ (quarto trimestre de 2016) git fetch é mais rápido.

Ver confirmar 5827a03 (13 de outubro de 2016) por Jeff King (peff).
^{(Mesclado por Júnio C Hamano-- gitster -- em cometer 9fcd144, 26 de outubro de 2016)}

fetch:use "rápido" has_sha1_file para seguir tags

Ao buscar de um controle remoto que possui muitas tags irrelevantes para os ramos que estamos seguindo, costumávamos perder muitos ciclos ao verificar se o objeto apontado por uma tag (que não vamos buscar!) existe em nosso repositório com muito cuidado.

Este patch ensina a busca a usar o has_sha1_quick para sacrificar a precisão da velocidade, nos casos em que podemos ser atrevidos com uma reembala simultânea.

Aqui estão os resultados do script perf incluído, que configura uma situação semelhante à descrita acima:

Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

Isso se aplica apenas a uma situação em que:

1. Você tem muitos pacotes do lado do cliente para fazer reprepare_packed_git() caro (a parte mais cara é encontrar duplicatas em uma lista não classificada, que atualmente é quadrática).
2. Você precisa de um grande número de referências de tags no lado do servidor que sejam candidatas ao acompanhamento automático (ou seja, que o cliente não possui).Cada um aciona uma releitura do diretório do pacote.
3. Em circunstâncias normais, o cliente seguiria automaticamente essas tags e, após uma grande busca, (2) não seria mais verdadeiro.
   Mas se essas tags apontarem para um histórico que está desconectado do que o cliente busca, então ele nunca será seguido automaticamente e esses candidatos terão impacto em cada busca.

---

Git 2.21 (fevereiro2019) parece ter introduzido uma regressão quando o configuração remote.origin.fetch é não o padrão ('+refs/heads/*:refs/remotes/origin/*')

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

Answer 2

Nota: Esta resposta é válida apenas para o Git v1.8 e mais antigo.

A maior parte disso foi dita nas outras respostas e comentários, mas aqui está uma explicação concisa:

• git fetch busca todas as cabeças de ramificação (ou todas especificadas pela opção de configuração remota.fetch), todos os cometidos necessários para eles e todas as tags que são acessíveis a partir dessas ramificações. Na maioria dos casos, todas as tags são acessíveis dessa maneira.
• git fetch --tags Geram todas as tags, todas as confirmam necessárias para elas. Será não Atualizar cabeças de ramificação, mesmo que sejam acessíveis a partir das tags que foram buscadas.

Resumo: Se você realmente deseja estar totalmente atualizado, usando apenas busca, você deve fazer as duas coisas.

Também não é "duas vezes mais lento", a menos que você queira dizer em termos de digitação na linha de comando; nesse caso, os aliases resolvem seu problema. Não há essencialmente nenhuma sobrecarga em fazer os dois pedidos, pois eles estão pedindo informações diferentes.

Answer 3

Eu vou responder isso sozinho.

Eu determinei que há uma diferença. "Git Fetch - -Tags" pode trazer todas as tags, mas não traz nenhuma nova confirmação!

Acontece que é preciso fazer isso para estar totalmente "atualizado", ou seja, replicou um "git pux" sem a fusão:

$ git fetch --tags
$ git fetch

Isso é uma pena, porque é duas vezes mais lento. Se apenas "Git Fetch" tivesse a opção de fazer o que normalmente faz e Traga todas as tags.

Answer 4

O problema geral aqui é que git fetch vai buscar +refs/heads/*:refs/remotes/$remote/*. Se alguma dessas confirmações tiver tags, essas tags também serão buscadas. No entanto, se houver tags não acessíveis por nenhuma filial no controle remoto, elas não serão buscadas.

o --tags a opção alterna o refSpec para +refs/tags/*:refs/tags/*. Você poderia perguntar git fetch para pegar os dois. Tenho certeza de apenas fazer um git fetch && git fetch -t Você usaria o seguinte comando:

git fetch origin "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/*"

E se você quiser fazer disso o padrão para este repositório, poderá adicionar um segundo refSpec à busca padrão:

git config --local --add remote.origin.fetch "+refs/tags/*:refs/tags/*"

Isso vai adicionar um segundo fetch = linha no .git/config Para este controle remoto.

---

Passei um tempo procurando o caminho para lidar com isso para um projeto. Foi isso que eu criei.

git fetch -fup origin "+refs/*:refs/*"

No meu caso, eu queria esses recursos

• Pegue todas as cabeças e tags do controle remoto, então use RefSpec refs/*:refs/*
• Substitua ramos locais e tags com não-rápido + Antes do refSpec
• Atualmente, sobrescrepou a filial, se necessário, se necessário -u
• Excluir galhos e tags não presentes no controle remoto -p
• E força para ter certeza -f

Answer 5

Na maioria das situações, git fetch Deve fazer o que você deseja, que é 'obter algo novo no repositório remoto e colocá -lo em sua cópia local sem se fundir para as filiais locais'. git fetch --tags Faz exatamente isso, exceto que não recebe nada, exceto novas tags.

Nesse sentido, git fetch --tags não é de forma alguma um superconjunto de git fetch. É de fato exatamente o oposto.

git pull, é claro, nada mais é do que um invólucro para um git fetch <thisrefspec>; git merge. É recomendável que você se acostuma a fazer manual git fetche git mergeantes de dar o salto para git pull simplesmente porque ajuda você a entender o que git pull está fazendo em primeiro lugar.

Dito isto, o relacionamento é exatamente o mesmo que git fetch. git pull é o superconjunto de git pull --tags.

Answer 6

git fetch upstream --tags

Funciona bem, ele só terá novas tags e não receberá outra base de código.