Git push yaparken "diff.renamelimit değişkeni" ile ilgili uyarı


87

Yerel kaydetmeyi uzak git sunucusuna gönderiyorum ve aşağıdaki uyarı mesajlarını alıyorum:

remote: warning: only found copies from modified paths due to too many files.
remote: warning: you may want to set your diff.renamelimit variable to at least 19824 and retry the command.

Ama aslında fark .renamelimit'i 0 olarak ayarladım (sıfırın sınırsız olduğunu düşünüyorum, değil mi?).

$ git config --list
...
diff.renamelimit=0

Peki bu uyarıdan kaçınmak için ne yapmalıyım? Teşekkürler.

Yanıtlar:


67

Dokümantasyon için özel bir değer olarak 0 bahsetmiyor diff.renamelimit.
Bu nedenle, bu sınırı önerilen değere ayarlamalısınız.
Veya yeniden adlandırma algılamasını tamamen devre dışı bırakmayı deneyebilirsiniz. ( git config diff.renames 0)

Bu blog gönderisinde benzer bir örnek bulacaksınız " Confluence, git, rename, merge oh my ... ":

Daha önce de belirtildiği gibi, git, örneğin git logveya kullanırken dosya yeniden adlarını algılamaya çalışır git diff/merge.
Yeniden adlandırmaları tespit etmeye çalışırken git, tam ve tam olmayan yeniden adlar arasında ayrım yapar, ilki dosyanın içeriğini değiştirmeden yeniden adlandırılır ve ikincisi, dosyanın içeriğindeki değişiklikleri içerebilecek bir yeniden adlandırma (örneğin, bir Java Sınıfını yeniden adlandırma / taşıma).
Bu ayrım önemlidir, çünkü tam olarak yeniden adlandırmaları tespit etmek için kullanılan algoritma doğrusaldır ve her zaman hatalı yeniden adlandırma algılaması için algoritma kuadratik ( O(n^2)) iken çalıştırılır ve değiştirilen dosya sayısı belirli bir eşiği (1000 x 1000) aşarsa git bunu varsayılan).

Son yapılan yeniden düzenlemeden etkilenen dosyaların sayısı bu eşiği aştığında, git basitçe vazgeçer ve birleştirme çözümünü geliştiriciye bırakır. Bizim durumumuzda, eşiği değiştirerek manuel birleştirme çözünürlüğü yapmaktan kaçınabiliriz


Not: Git 2.16 (Q1 2018) bu limiti değiştirecek:

Tarihsel olarak, yeniden adlandırma tespiti için diff makinesinin sabit kodlanmış 32k yolu sınırı vardı; bu, kullanıcıların (muhtemelen) okunması daha kolay bir sonuçla ticaret döngülerini mümkün kılmak için kaldırılıyor.

Bkz. 8997355 (29 Kasım 2017), Jonathan Tan ( jhowtan) .
Bkz. 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (13 Kasım 2017) by Elijah Newren ( newren) .
(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 6.466.854 tamamlama 2017 19 Ara)

diff: sessiz kelepçeyi çıkarın renameLimit

Gelen 0024a54 tamamlama (adlandırma saptama sınırı kontrolü saptamak; Eylül 2007, Git v1.5.3.2), renameLimit32767 sabitlemeyi
sadece aşağıdaki hesaplama taşma tamsayıdır önlemek olmuştur Bu görüntülenene:

num_create * num_src <= rename_limit * rename_limit

Her ne kadar CPU süresi miktarına bağlı olarak sabit kodlanmış bir sınır olarak görülebilecek olsa da, kullanıcıların git'e yeniden adların işlenmesi için harcamalarını söylemelerine izin vermeye hazırız.
Bir üst sınır mantıklı olabilir, ancak ne yazık ki bu üst sınır ne kullanıcılara iletilmiş ne de herhangi bir yerde belgelenmiştir.

Büyük sınırlar işleri yavaşlatabilse de, büyük bir sınırı manuel olarak belirtmeleri ve yeniden adların algılanması için on dakika beklemeleri gerekse bile, küçük bir beş dosya değişikliğine sahip olmaktan mutluluk duyacak kullanıcılarımız var.

-l0Çalışmaya devam etmek için " " kullanan mevcut komut dosyaları ve araçlar, 0'ı yeniden adlandırma sınırının çok büyük bir sayı olacağını belirten özel bir değer olarak ele alır.


Git 2.17 (Q2 2018), bir " git diff" çıktı satırının ortasında bir uyarı mesajı göstermekten kaçınacaktır .

Bkz. Commit 4e056c9 (16 Ocak 2018), Nguyenễn Thái Ngọc Duy ( pclouds) .
(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 17c8e0b tamamlama 2018 Şubat 13)

diff.c: stdoutyeniden adlandırma uyarılarını yazdırmadan önce yıkayın

Diff çıktısı bir FILEnesnede arabelleğe alınır ve bu uyarıları yazdırdığımızda (doğrudan üzerine fd 2) kısmen arabelleğe alınabilir .
Çıktı böyle dağınık

 worktree.c                                   |   138 +-
 worktree.h        warning: inexact rename detection was skipped due to too many files.
                           |    12 +-
 wrapper.c                                    |    83 +-

Grafik bölümü için renk kodları zaten yazdırıldıktan sonra uyarı yazdırılırsa daha da kötüleşir. Yeşil veya kırmızı renkte bir uyarı alacaksınız.

Önce stdout'u temizleyin, böylece bunun yerine şuna benzer bir şey elde edebiliriz:

 xdiff/xutils.c                               |    42 +-
 xdiff/xutils.h                               |     4 +-
 1033 files changed, 150824 insertions(+), 69395 deletions(-)
warning: inexact rename detection was skipped due to too many files.

82
git config merge.renameLimit 999999

Merge.renameLimit ne anlama geliyor?

Birleştirme sırasında yeniden adlandırma algılaması gerçekleştirilirken dikkate alınacak dosya sayısı; belirtilmezse, varsayılan olarak diff.renameLimit değeri kullanılır .

kaynak: https://git-scm.com/docs/git-merge


35
neden merge.renameLimitbunun yerine diff.renameLimit?
pgpb.padilla

@ pgpb.padilla çok benzer
Sandra K

4
git config diff.renameLimit 999999 (kendi numaranızı girin) benim için çalıştı.
elarcoiris

2
Birisi olabilir bir neden var mı yok max için bu out istiyor? Sınır neden ilk etapta var? İşlemcinizi delicesine büyük birleşmelerden kurtarmak için mi?
electrovir

@ pgpb.padilla, uyarım şöyle dedi: uyarı: merge.renamelimitdeğişkeninizi en az 1659 olarak ayarlamak ve komutu yeniden denemek isteyebilirsiniz . Yani, git config merge.renamelimit 10000benim için doğru komut gibi görünüyor (burada limiti 10000'e ayarlıyorum). Bir kez ayarladıktan sonra, ayarınızı ile geri okuyabilirsiniz git config merge.renamelimit.
Gabriel Staples
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.