Bir taahhüdün başka bir taahhüdün torunu olup olmadığını nasıl anlarım?

Git ile şubemdeki bir taahhüdün başka bir taahhüdün torunu olup olmadığını nasıl anlarım?

Bunu programlı olarak kontrol etmek istiyorsanız (örn. Komut dosyasında), git merge-base A Beşit olup olmadığını git rev-parse --verify A(o zaman A'ya B'den ulaşılabilir mi), yoksa git rev-parse --verify B(B'ye A'dan ulaşılabildiğini) kontrol edebilirsiniz. git rev-parseBurada, taahhüt adından SHA-1 / taahhüt kimliğine dönüştürmek gerekir.

VonC cevabında olduğu git rev-listgibi kullanmak da mümkündür.

Düzenleme: modern Git şeklinde bu sorgu için açık destek vardır git merge-base --is-ancestor.

Eğer sorduğunuz taahhütlerden biri bir şube ipucu ise , o zaman git branch --contains <commit>ya git branch --merged <commit>da daha iyi programatik olmayan bir çözüm olabilir.

Git 1.8.0 sürümünden bu seçenek aşağıdakiler için desteklenir merge-base:

git merge-base --is-ancestor <maybe-ancestor-commit> <descendant-commit>

Man sayfasından:

--is-ata

Birincisinin ikincinin atası olup olmadığını kontrol edin ve doğruysa 0 durumuyla veya değilse 1 durumuyla çıkın. Hatalar 1 olmayan sıfırdan farklı bir durumla bildirilir.

Örneğin:

git merge-base --is-ancestor origin/master master; echo $?

Bu tür işlemler SO sorusunda ayrıntılarıyla belirtilen revizyon aralığı fikrine dayanır : " 'git log origin / master' ve 'git log origin / master ..' " arasındaki fark.

git rev-list ulaşılabiliyorsa, bir taahhütten diğerine kadar yürüyebilmelidir.

Bu yüzden denerdim:

git rev-list --boundary 85e54e2408..0815fcf18a
0815fcf18a19441c1c26fc3495c4047cf59a06b9
8a1658147a460a0230fb1990f0bc61130ab624b2
-85e54e240836e6efb46978e4a1780f0b45516b20

(Sınır taahhütlerinin önüne ek gelir -)

Görüntülenen son işlem, komuttaki ilk işlemle aynıysa git rev-list, ikinci işlemden erişilebilen bir işlemdir.

İlk taahhüt ikinciden ulaşılamazsa, git rev-listhiçbir şey döndürmemelidir.

git rev-list --boundary A..B

tarafından bitirmek istiyorum Aeğer Agelen ulaşılabilir B.
Aynı:

git rev-list --boundary B --not A

ile Bbir pozitif referans ve Abir negatif referans .
Şuradan başlar Bve ulaşılabilir bir revizyonla karşılaşıncaya kadar grafikte geriye doğru yürür A.
Ben eğer iddia ediyorum Adoğrudan ulaşılabilir B, bu (çünkü, ve ekran karşılaşacak --boundaryseçeneği) Akendisini.

Başka bir yol kullanmak git logve olacaktır grep.

git log --pretty=format:%H abc123 | grep def456

Bu, kesinleştirme def456, kesinleştirme abc123'ün bir atasıysa veya başka bir çıktı yoksa, bir çıktı satırı üretecektir.

Genellikle --prettyargümanı atlamaktan kurtulabilirsiniz , ancak günlük yorumları vb. İle değil, yalnızca gerçek taahhüt karmaları ile arama yaptığınızdan emin olmak istiyorsanız gereklidir.

https://stackoverflow.com/a/13526591/895245 bundan daha insan dostu hale getirmek için bahsediyor:

git-is-ancestor() (
  if git merge-base --is-ancestor "$1" "$2"; then
      echo 'ancestor'
  elif git merge-base --is-ancestor "$2" "$1"; then
      echo 'descendant'
  else
      echo 'unrelated'
  fi
)
alias giia='git-is-ancestor'

git gösteri-şube şube-sha1 taahhüt-sha1

Nerede:

• branch-sha1: şubenizdeki kontrol etmek istediğiniz sha1
• commit-sha1: kontrol etmek istediğiniz taahhüdün sha1'i

Kullanıyorsanız git merge-base --is-ancestor, Git 2.28 (Q3 2020) kullandığınızdan emin olun.

Git 2.28 (Q3 2020) ile, " struct commit" içerisindeki her zaman bulunması gerekmeyen birkaç alan, döşeme işlemek için taşınmıştır.

Bkz. C752ad0 , c49c82a , 4844812 , 6da43d9 (17 Haziran 2020), Abhishek Kumar ( abhishekkumar2718) .
^{(Tarafından Birleştirilmiş Junio C Hamano - gitster- içinde taahhüt d80bea4 , 6 Temmuz 2020)}

commit-graph: takdim etmek commit_graph_data_slab

^{İmzalayan: Abhishek Kumar}

Yapı taahhüdü birçok bağlamda kullanılır. Ancak, üyeler generationve graph_possadece kesin grafik ile ilgili işlemler için kullanılır ve aksi takdirde bellek boşa.

Bu israf, mevcut 32 bit yerine 64 bit nesil sayısı kullanan v2 nesil numarasına geçiş yaptığımızda daha belirgin olurdu.

Sıklıkla birlikte eriştikleri için, yapıyı tanıtalım commit_graph_datave bunları bir commit_graph_datalevhaya taşıyalım .

Genel test takımı master(seri: 26m48s master,: 27m34s,% 2.87 daha hızlı) kadar hızlı çalışırken, Szeder Gábor'un keşfettiği gibi bazı komutlar git merge-base --is-ancestor% 40 yavaşladı . Kesim levhası erişimini en aza indirdikten sonra, yavaşlama devam eder, ancak% 20'ye yakındır.

Derrick Stolee yavaşlamanın alt yapı erişiminin yavaşlığından ziyade altta yatan algoritmaya atfedilebileceğine inanıyor ve daha sonraki bir dizide takip edeceğiz.

Depodaki tüm etiketler için bunu yapmanız gerektiğinde, itub'ın cevabına dayanarak:

for i in `git tag` ; do echo -ne $i "\t" ; git log --pretty=format:%H $i | (grep <commit to find> || echo ""); done