Git'te dalın karması nasıl bulunur?

Yerel / uzak bir şube adı verildiğinde, bu şubenin işaret ettiği kesinleştirme karmasını nasıl alabilirim?

Komut git rev-parsearkadaşınızdır, örneğin:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... veya bir uzaktan izleme dalı için:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

Bu komut genellikle çok kullanışlıdır, çünkü içinde dal adlarını belirtmenin yollarından herhangi birini ayrıştırabilir git, örneğin:

git rev-parse master~3
git rev-parse HEAD@{2.days.ago}

... vb.

Karmalar .git/refs/, ör..git/refs/heads/master

Ancak git rev-parsedaha güvenli olduğu için Mark Longair tarafından önerildiği gibi programatik olarak kullanın .

Git 2.19'dan (Q2 2018) bu yana Git'in SHA1 karmalarından SHA2'ye bir geçiş hazırladığını unutmayın: bkz. " Git neden daha modern SHA kullanmıyor? "

Git 2.25 ile (Q1 2020), git rev-parse gelişir ve bu olası yeni hash'i yansıtır.

Bkz fa26d5e işlemek , cf02be8 işlemek , 38ee26b işlemek , işlemek 37ab8eb , 0370b35 taahhüt , 0253e12 taahhüt , 45e2ef2 taahhüt , 79b0edc işlemek , 840624f taahhüt , 32a6707 taahhüt , 440bf91 taahhüt , 0b408ca işlemek , 2eabd38 taahhüt (2019 28 Eki) ve 1bcef51 taahhüt , taahhüt ecde49b (05 Eki 2019), yazan brian m. carlson ( bk2204) .
^{( Junio ​​C Hamano ile birleştirildi - gitster- içinde 28014c1 tamamlama , 10 Kas 2019)}

rev-parse: --show-object-formatseçenek ekle

^{İmza: Brian m. Carlson}

Giriş, çıkış veya depolama için kullanılan nesne formatını yazdırmak için bir seçenek ekleyin.
Bu, kabuk komut dosyalarının kullanılan karma algoritmayı keşfetmesine olanak tanır.

Geçiş planı birden çok girdi algoritmasına izin verdiğinden, girdi için birden çok sonuç sağlayabileceğimizi ve sonuçların alabileceği biçimi belgeleyin.
Bunu şu anda desteklemesek de, erken belgelemek, senaryo yazarlarının bizim yaptığımız zaman senaryolarını geleceğe hazırlayabilecekleri anlamına gelir.

git rev-parseDokümantasyon şimdi içerir:

--show-object-format[=(storage|input|output)]:

.gitDizin, giriş veya çıkış içinde depolama için depo için kullanılan nesne formatını (karma algoritma) gösterin . Giriş için, birden fazla algoritma basılabilir, boşlukla ayrılmış olabilir. Belirtilmezse, varsayılan "depolama" dır.

Git 2.29 (Q4 2020) ile, bir dalın (veya başka herhangi bir nesnenin) karma kaydını okumak için hangi formatı kullanmanız gerektiğinden emin olabilirsiniz.

Bkz e023ff0 işlemek , 4feb562 taahhüt , 8a06d56 taahhüt , c49fe07 işlemek , 02a32db işlemek , ceaa4b3 işlemek , eff45da işlemek , b5b46d7 işlemek , işlemek c5aecfc , e74b606 taahhüt , 439d3a1 taahhüt , 6c2adf8 taahhüt , de5737c işlemek , işlemek e0a646e , 6ff6a67 taahhüt , 831279d işlemek , işlemek b6e5005 , commit 287bb3a , commit 22f1824 , commit db00af9 ,7187eb1 işlemek , 98de0b2 işlemek , a5587b8 işlemek , 66b6d43 işlemek , 2197f87 işlemek , c0b65ea işlemek , d62607d işlemek , tamamlama d482c23 , 866be6e işlemek , 4bacb6d işlemek , 252a4ee işlemek , 368f3cb işlemek , tamamlama abe3db1 , 08fbc5d işlemek , 11b6961 işlemek , 9e3bd8a işlemek , d827bce işlemek , commit 094a685 (29 Tem 2020) by brian m. carlson ( bk2204) .
Görmek800e6a7(29 Temmuz 2020), Johannes Schindelin ( dscho) .
^{( Junio ​​C Hamanogitster tarafından birleştirildi - - in commit e0ad957 , 11 Ağu 2020)}

docs: için belge ekle extensions.objectFormat

^{İmza: Brian m. carlson
İnceleyen: Eric Sunshine}

extensions.objectFormatYapılandırma ayarını belgeleyin .
Kullanıcıları kendilerinin değiştirmemeleri konusunda uyarın.

git configartık man sayfasında şunları içeriyor :

extensions.objectFormat

Kullanılacak karma algoritmayı belirtin.

Kabul edilebilir değerler sha1ve> sha256.
Belirtilmezse sha1varsayılır. 1
olmadığı sürece bu anahtarı belirtmek bir hatadır core.repositoryFormatVersion.

Bu ayarın yalnızca git initveya ile yapılması gerektiğini unutmayın git clone.
Başlatma sonrasında onu değiştirmeye çalışmak işe yaramayacak ve teşhis edilmesi zor sorunlar yaratacaktır.

Açık olmak gerekirse, Git 2.29 (Q4 2020) ile, en son eklenen SHA-256 desteği, belgelerde deneysel olarak işaretlenmiştir .

Bakınız commit ff233d8 (16 Ağu 2020), Martin Ågren ( none) .
^{( Junio ​​C Hamanogitster tarafından birleştirildi - - in commit d1ff741 , 24 Ağu 2020)}

Documentation: --object-format=sha256deneysel olarak işaretle

^{İmza: Martin Ågren}

Eff45daab8'den sonra (" repository: varsayılan olarak SHA-256 desteğini etkinleştir", 2020-07-29, Git v2.29.0 - toplu işlemde listelenen birleştirme ), Git'in vanilya yapıları kullanıcının çalışmasını sağlar, ör.

git init --object-format=sha256  

ve hackleyin.
Bu, SHA-256 dünyası ile deneyim kazanmak için iyi bir yol olabilir, ör.

GIT_TEST_DEFAULT_HASH=sha256 make test  

nokta değil.

Ama gerçekten ayrı bir dünya: Bu tür SHA-256 depoları (artık oldukça büyük olan) SHA-1 depolarından tamamen ayrı yaşayacak.
Sınır ötesi etkileşim prensipte, örneğin " diff+ apply" (veya " format-patch+ am") yoluyla mümkündür , ancak bunun bile sınırlamaları vardır: Bir SHA-1 deposunda bir SHA-256 farkının uygulanması basit durumda işe yarar, ancak başvurmanız gerekiyorsa -3, şansınız yok.

Benzer şekilde, " push+ pull" çalışmalıdır, ancak gerçekten dünyanın geri kalanından çoğunlukla ofset çalışacaksınız. [Deponuzu başlattığınızda bu sorun olmayabilir ve bundan sonraki birkaç ay için sorun olmayabilir, ancak git init --object-format = sha256 kullanımınıza pişman olmaya başladığınız bir gün gelebilir ](https://github.com/git/git/blob/ff233d8dda12657a90d378f2b403bc6c85838c59/Documentation/git-init.txt#L52)<sup>([man](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt))</sup>ve kendini oldukça derin bir çukura kazdın.

SHA-256 ile ilgili veri formatlarımızı ve protokollerimizi belgelemek için şu anda uçuşta olan konular var ve bazı durumlarda (midx ve commit-graph), dosya formatlarının hangi nesne formatının kullanılacağını nasıl belirlediğini ayarlamayı düşünüyoruz.

--object-formatDokümantasyonumuzda bahsedildiği her yerde , onu "sha256" ile kullanmanın deneysel olduğunu açıkça belirtelim.
Daha sonra 2020'de ürettiğimiz verileri neden işleyemediğimizi açıklamamız gerekirse, buraya eklediğimiz bu paragrafa her zaman işaret edebiliriz.

"İnclude ::" - küçük bir tanıtım yazarak, dokümantasyon boyunca tutarlı olabilir ve sonunda bu metnin ciddiyetini yavaş yavaş azaltabiliriz.
Bir gün onu aşamalı olarak bitirmek için bile kullanabiliriz --object-format=sha1, ama kendimizin önüne geçmeyelim ...

Ayrıca var extensions.objectFormat, ama sadece üç kez bahsediliyor. Bu yeni sorumluluk reddini iki kez eklediğimiz yerde ve üçüncü noktada zaten bir "düzenleme" uyarısı görüyoruz. Oradan, ilgilenen okuyucular sonunda buraya eklediğimiz bu yenisini bulmalıdır.

Çünkü GIT_DEFAULT_HASHbu işlevi için başka giriş noktası sağlar, çok bunun deneysel doğasını belgelemek.

gitartık man sayfasında şunları içeriyor :

bunun yerine kullanılır. Varsayılan "sha1" dir. BU DEĞİŞKEN DENEYSELDİR! Bkz --object-formatiçinde git init.

object-format-disclaimerartık man sayfasında şunları içeriyor :

BU SEÇENEK DENEYSELDİR!
SHA-256 desteği deneyseldir ve halen erken bir aşamadadır.

Bir SHA-256 deposu, genel olarak> işi "normal" SHA-1 depolarıyla paylaşamayacaktır.
SHA-256 depoları ile ilgili olarak Git dahili dosya formatlarının geriye dönük uyumsuz şekillerde değişebileceği varsayılmalıdır.
Yalnızca --object-format=sha256test amaçlı kullanın .

Aynı Git 2.29 (Q4 2020) , SHA-1 deposundan bir klon yapıldığında " git clone" ^{( adam )} çalışacağından emin olurken GIT_DEFAULT_HASH, zaten SHA-256 kullanacak şekilde ayarlandı.
2.29'dan önce, bu, yarı-SHA-1 nesneleri ve başvuruları içeren SHA-256 havuzu olduğunu iddia eden, kullanılamaz bir havuzla sonuçlandı.
Bu düzeltildi.

See commit 47ac970 (20 Eyl 2020) by brian m. carlson ( bk2204) .
^{( Junio ​​C Hamano ile birleştirildi - gitster- in commit b28919c , 29 Eyl 2020)}

builtin/clone: ile başarısızlığı önlemek GIT_DEFAULT_HASH

^{Bildiren: Matheus Tavares
İmza: brian m. Carlson}

Bir kullanıcı GIT_DEFAULT_HASH" sha256" olarak ayarlanmış bir SHA-1 havuzunu klonluyorsa , o zaman depo formatı sürümünün 0 olduğu ancak extensions.objectformatanahtarın " sha256" olarak ayarlandığı bir havuzla sonlandırabiliriz .
Bu hem yanlıştır (kullanıcının bir SHA-1 deposu vardır) hem de işlevsizdir (çünkü uzantı bir v0 havuzunda kullanılamaz).

Bunun nedeni, bir klonda, başlangıçta depoyu kurmamız ve ardından uzak tarafın bize kullandığını söylediklerine göre algoritmasını değiştirmemizdir.
Bu durumda ilk olarak depoyu SHA-256 olarak kurduk ve daha sonra uzantıyı temizlemeden depo sürümünü sıfırladık.

Uzantıyı bu durumda her zaman ayarlayabilirdik, ancak bu, SHA-1 depolarımızın, olmamaları için bir neden olmasa bile eski Git sürümleriyle uyumlu olmadığı anlamına gelir.
Ayrıca depoyu başlangıçta SHA-1 olarak başlatmak istemiyoruz, çünkü bu, eğer boş bir depoyu klonluyorsak, GIT_DEFAULT_HASHdeğişkeni onurlandırmada başarısız olacağız ve sonunda bir SHA-1 deposu elde edeceğiz, değil bir SHA-256 deposu.

Bunların hiçbiri çekici değil, bu yüzden eğer böyle bir yeniden başlatma yapıyorsak depo başlatma kodunu söyleyelim ve eğer öyleyse, SHA-1 kullanıyorsak uzantıyı temizleyelim.
Bu, geçerli ve işlevsel bir havuz oluşturmamızı sağlar ve diğer kullanım durumlarımızdan hiçbirini bozmaz.