“Git fetch --tags” “git fetch” içerir mi?

Güzel ve basit bir soru - "git fetch" işlevi katı bir alt küme git fetch --tagsmidir?

Yani koşarsam git fetch --tags, hemen git fetchsonra koşmak için bir sebep var mı?

Ne hakkında git pullve git pull --tags? Aynı durum?

Not: ile başlayan Git 1.9 / 2.0 (Q1 2014) , git fetch --tagsetiketler getirir ilaveten seçeneği olmadan aynı komut satırı ile getirilen nelerdir.

Michael Haggerty (mhagger) tarafından taahhüt c5a84e9'a bakınız :

Önceden, getirme işleminin " --tags" seçeneği refspec belirtmeye eşdeğer olarak kabul ediliyordu

refs/tags/*:refs/tags/*

komut satırında; özellikle, remote.<name>.refspecyapılandırmanın göz ardı edilmesine neden oldu .

Ancak diğer referanslar getirilmeden etiketlerin getirilmesi çok yararlı olmazken, diğer referanslara ek olarak etiketlerin getirilmesi de oldukça yararlıdır . Bu yüzden ikincisini yapmak için bu seçeneğin anlamını değiştirin.

Bir kullanıcı yalnızca etiketleri almak istiyorsa , açık bir refspec belirtmek yine de mümkündür:

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

1.8.0.3'ten önceki belgelerin " fetch --tags" davranışının bu yönü hakkında belirsiz olduğunu lütfen unutmayın .
F0cb2f1 ( 2012-12-14 ) taahhüdüfetch --tags dokümantasyonu eski davranışa uygun hale getirdi.
Bu işlem, belgeleri yeni davranışa uyacak şekilde değiştirir (bkz. Documentation/fetch-options.txt).

Alınan her şeye ek olarak tüm etiketlerin uzaktan kumandadan getirilmesini isteyin .

Git 2.5 (2. Çeyrek 2015) git pull --tagsdaha sağlam olduğu için:

Bkz 19d122b taahhüt tarafından Paul Tan ( pyokagan) , 13 Mayıs 2015
^{(tarafından Birleştirilmiş Junio C Hamano - gitster- içinde cc77b99 işlemek 2015 22 Mayıs)}

pull: --tagsbirleştirme adayı durumunda hatayı kaldır

Yana 441ed41 (" git pull --tags:". Daha iyi bir mesajla dışarı hatası, 2007-12-28, Git 1.5.4+), git pull --tagseğer farklı bir hata mesajı yazdırmak istiyorum git-fetchherhangi birleştirme adayları dönmedi:

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

Bunun nedeni, o sırada git-fetch --tagsyapılandırılmış refspec'leri geçersiz kılacağı ve dolayısıyla birleştirme adayı olmayacağıdır. Hata mesajı böylece karışıklığı önlemek için getirildi.

Ancak, c5a84e9 ( fetch --tags: diğer öğelere ek olarak etiketleri getir , 2013-10-30, Git 1.9.0+), git fetch --tagsyapılandırılmış refspec'lere ek olarak etiketleri getirir.
Bu nedenle, herhangi bir birleştirme adayı durumu meydana gelmezse, bunun nedeni --tagsbelirlenmiş değildir . Bu nedenle, bu özel hata mesajı artık önemsizdir.

Karışıklığı önlemek için bu hata iletisini kaldırın.

Git 2.11+ (2016 4. Çeyrek) git fetchile daha hızlı.

Bkz. Taahhüt: 5827a03 (13 Ekim 2016) - Jeff King ( peff) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 9fcd144 tamamlama 2016, 26 Eki)}

fetch: has_sha1_fileetiket takibi için "hızlı" kullanın

Takip ettiğimiz dallarla alakasız birçok etiketi olan bir uzaktan kumandadan getirilirken, depomuzda (getirmeyeceğimiz!) Bir etiketin işaret ettiği nesnenin var olup olmadığını kontrol ederken çok fazla döngü harcıyorduk. dikkatlice.

Bu yama, eşzamanlı bir yeniden paketleme ile açık olabileceğimiz durumlarda, hız doğruluğunu feda etmek için HAS_SHA1_QUICK'i kullanmayı öğretir.

Yukarıda belirtilene benzer bir durum oluşturan dahil edilen mükemmel komut dosyasının sonuçları şunlardır:

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

Bu sadece aşağıdaki durumlarda geçerlidir:

1. reprepare_packed_git()Pahalı hale getirmek için müşteri tarafında çok fazla paketiniz var (en pahalı kısım, şu anda ikinci dereceden olan sıralanmamış bir listede kopyaları bulmaktır).
2. Sunucu tarafında, otomatik takip için aday olan (yani istemcinin sahip olmadığı) çok sayıda etiket referansına ihtiyacınız vardır. Her biri paket dizininin yeniden okunmasını tetikler.
3. Normal şartlar altında, müşteri bu etiketleri otomatik olarak takip eder ve bir büyük getirmeden sonra (2) artık doğru olmaz.
   Ancak bu etiketler, istemcinin başka şekilde getirdiği bağlantıdan kopmuş bir tarihe işaret ediyorsa, asla otomatik olarak takip edilmez ve bu adaylar her getiride etkileyecektir.

Git 2.21 (2019 Şubat) ne zaman bir gerileme oluşturmuş gibi görünüyor yapılandırma remote.origin.fetcholduğunu değil varsayılan bir ( '+refs/heads/*:refs/remotes/origin/*')

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

Git 2.24 (4. Çeyrek 2019) bir optimizasyon daha ekliyor.

Bakınız Masaya Suzuki ( ) tarafından taahhüt edilen b7e2d8b (15 Eyl 2019 ) . ^{(Tarafından Birleştirilmiş - Junio C Hamano - içinde 1d8b0df taahhüt 2019 7 Ekim,)}draftcode
gitster

fetch: oidsetdaha hızlı arama için istenen OID'leri tutmak için kullanın

Sırasında git fetchistemci, reklamı yapılan etiketlerin OID'lerinin getirme isteğinin OID ayarında olup olmadığını kontrol eder.
Bu kontrol doğrusal bir taramada yapılır.
Çok fazla referansa sahip bir havuz için, bu taramayı tekrarlamak 15 dakikadan fazla sürer.

Bunu hızlandırmak için, oid_setdiğer referansların OID'leri için bir a oluşturun .

Not: Bu cevap yalnızca git v1.8 ve daha eski sürümler için geçerlidir.

Bunların çoğu diğer cevaplarda ve yorumlarda söylendi, ancak kısa bir açıklama:

• git fetchtüm şube başlıklarını (veya remote.fetch yapılandırma seçeneği tarafından belirtilenleri), onlar için gerekli olan tüm işlemleri ve bu şubelerden erişilebilen tüm etiketleri getirir. Çoğu durumda, tüm etiketlere bu şekilde erişilebilir.
• git fetch --tagstüm etiketleri getirir, onlar için gerekli olan tüm taahhütler. Bu olacak değil onlar getirilen vardı etiketlerinden ulaşılabilir bile, şube başkanları güncelleyin.

Özet: Yalnızca getirmeyi kullanarak gerçekten güncel olmak istiyorsanız, her ikisini de yapmanız gerekir.

Komut satırına yazmayı kastediyorsanız, bu durumda takma adlar sorununuzu çözmezse "iki kat daha yavaş" değildir. Farklı bilgi talep ettiklerinden, iki talebin yapılmasında esasen herhangi bir ek yük yoktur.

Buna kendim cevap vereceğim.

Bir fark olduğunu belirledim. "git fetch --tags" tüm etiketleri getirebilir, ancak yeni taahhüt getirmez!

Tamamen "güncel" olmak için bunu yapmak zorunda olduğu ortaya çıkıyor, yani bir "git pull" birleştirmeden çoğaltılmış:

$ git fetch --tags
$ git fetch

Bu bir utanç, çünkü iki kat daha yavaş. Sadece "git fetch" in normalde yaptığı şeyi yapma ve tüm etiketleri getirme seçeneği olsaydı .

Buradaki genel sorun git fetch, getirilecek olmasıdır +refs/heads/*:refs/remotes/$remote/*. Bu işlemlerden herhangi birinin etiketi varsa, bu etiketler de getirilir. Ancak, uzaktan kumandadaki herhangi bir dal tarafından erişilemeyen etiketler varsa, bunlar getirilmez.

--tagsSeçeneğini refspec geçer +refs/tags/*:refs/tags/*. Sen olabilir sormak git fetchhem kapmak için. Sadece git fetch && git fetch -taşağıdaki komutu kullanacağınızdan eminim :

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

Bunu bu repo için varsayılan yapmak istiyorsanız, varsayılan getirmeye ikinci bir refspec ekleyebilirsiniz:

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

Bu, bu uzaktan kumanda için ikinci bir fetch =satır ekleyecektir .git/config.

Bunu bir proje için halletmenin yolunu aramak için biraz zaman harcadım. Ben de bunu buldum.

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

Benim durumumda bu özellikleri istedim

• Uzaktan kumandadaki tüm kafaları ve etiketleri alın, bu yüzden refspec kullanın refs/*:refs/*
• +Refspec'den önce hızlı ileri olmayan yerel şubelerin ve etiketlerin üzerine yaz
• Gerekirse, şu anda kullanıma alınmış şubenin üzerine yaz -u
• Uzaktan kumandada bulunmayan dalları ve etiketleri sil -p
• Ve emin olmak için zorlayın -f

Çoğu durumda, git fetch'uzak depodan yeni bir şey alın ve yerel şubelerinizle birleşmeden yerel kopyanıza koyun' olan istediğinizi yapmalısınız. git fetch --tagstam olarak bunu yapar, ancak yeni etiketler dışında hiçbir şey almaz.

Bu anlamda, git fetch --tagshiçbir şekilde bir üst küme değildir git fetch. Aslında tam tersi.

git pull, elbette, a için bir sarıcıdan başka bir şey değildir git fetch <thisrefspec>; git merge. Atlamayı yapmadan önce manuel git fetching ve git mergeing yapmaya alışmanız önerilir, git pullçünkü git pullilk etapta ne yaptığınızı anlamanıza yardımcı olur .

Bununla birlikte, ilişki tam olarak aynıdır git fetch. git pull'nin süper setidir git pull --tags.

git fetch upstream --tags

gayet iyi çalışıyor, sadece yeni etiketler alacak ve başka bir kod tabanı almayacak.