Git'te, geçerli commit karmasını aynı commit'deki bir dosyaya nasıl yazabilirim

Burada Git kancalarıyla süslü şeyler yapmaya çalışıyorum, ancak bunu nasıl yapacağımı gerçekten bilmiyorum (veya mümkünse).

Yapmam gereken şey şudur: Her kayıtta hashini almak ve ardından bu hash ile commit'deki bir dosyayı güncellemek istiyorum.

Herhangi bir fikir?

Aklınızdan geçenlere benzer bir şey yapmanızı tavsiye ederim: SHA1'i derleme / kurulum / dağıtım sürecinin bir parçası olarak oluşturulan izlenmeyen bir dosyaya yerleştirmek. Yapması açıkça kolay ( git rev-parse HEAD > filenameveya belki de git describe [--tags] > filename) ve git'in izlediğinden farklı bir dosyayla sonuçlanmak gibi çılgınca şeyler yapmaktan kaçınıyor.

Kodunuz daha sonra sürüm numarasına ihtiyaç duyduğunda bu dosyaya başvurabilir veya bir oluşturma işlemi bilgileri son ürünle birleştirebilir. İkincisi aslında git'in sürüm numaralarını nasıl elde ettiğidir - derleme süreci sürüm numarasını depodan alır, ardından çalıştırılabilir dosyada oluşturur.

Mevcut commit karmasını yazmak imkansızdır: gelecekteki commit karmasını önceden hesaplamayı başarırsanız - herhangi bir dosyayı değiştirir değiştirmez değişecektir.

Ancak üç seçenek vardır:

1. 'Commit kimliğini' artırmak ve bir yere eklemek için bir komut dosyası kullanın. Çirkin
2. .gitignore, hash'i saklayacağınız dosyayı. Çok kullanışlı değil
3. İçinde pre-commit, önceki commit karmasını saklayın :) % 99.99 durumda commit'leri değiştirmez / eklemezsiniz, bu yüzden bu çalışacaktır. En kötü durumda, kaynak revizyonunu hala tanımlayabilirsiniz.

Bir kanca senaryosu üzerinde çalışıyorum, 'bittiğinde' buraya göndereceğim, ama yine de - Duke Nukem Forever'ın piyasaya çıkmasından önce :))

Güncelleme : kod .git/hooks/pre-commit:

#!/usr/bin/env bash
set -e

#=== 'prev-commit' solution by o_O Tync
#commit_hash=$(git rev-parse --verify HEAD)
commit=$(git log -1 --pretty="%H%n%ci") # hash \n date
commit_hash=$(echo "$commit" | head -1)
commit_date=$(echo "$commit" | head -2 | tail -1) # 2010-12-28 05:16:23 +0300

branch_name=$(git symbolic-ref -q HEAD) # http://stackoverflow.com/questions/1593051/#1593487
branch_name=${branch_name##refs/heads/}
branch_name=${branch_name:-HEAD} # 'HEAD' indicates detached HEAD situation

# Write it
echo -e "prev_commit='$commit_hash'\ndate='$commit_date'\nbranch='$branch'\n" > gitcommit.py

Şimdi ihtiyacımız olan tek şey, prev_commit,branchçifti gerçek bir commit karmasına dönüştüren bir araçtır :)

Bu yaklaşımın birleştirme taahhütlerini birbirinden ayırıp anlatamayacağını bilmiyorum. Yakında kontrol edeceğim

Birisi beni ident ile ilgili "man gitattributes" bölümüne işaret etti.

ident

Öznitelik kimliği bir yol için ayarlandığında, git, blob nesnesindeki $ Id $ 'ı $ Id: ile değiştirir, ardından 40 karakterlik onaltılık blob nesnesi adı ve ardından ödeme sırasında dolar işareti $ gelir. $ Id: ile başlayan ve çalışma ağacı dosyasında $ ile biten herhangi bir bayt dizisi, giriş sırasında $ Id $ ile değiştirilir.

Düşünürseniz, CVS, Subversion vb. De bunu yapar. Depoya bakarsanız, arşivdeki dosyanın her zaman örneğin $ Id $ içerdiğini görürsünüz. Asla onun genişlemesini içermez. Yalnızca ödeme sırasında metnin genişletilmesi sağlanır.

Bu, gitattributes içindeki filteröznitelik kullanılarak elde edilebilir . smudgeKaydetme kimliğini ekleyen bir cleankomut ve onu kaldıran bir komut sağlamanız gerekir, böylece eklenen dosya yalnızca commit kimliği nedeniyle değişmez.

Bu nedenle, kesinleştirme kimliği hiçbir zaman dosyanın blobunda saklanmaz; sadece çalışma kopyanızda genişletilmiş. (Aslında commit kimliğini blob'a eklemek sonsuz bir yinelemeli görev haline gelir. ☺) Bu ağacı klonlayan herhangi birinin öznitelikleri kendisi için ayarlaması gerekir.

Taahhüt kutusunun dışında düşünün!

bunu dosya kancalarına / çıkış sonrası

#!/bin/sh
git describe --all --long > config/git-commit-version.txt

Sürüm, kullandığınız her yerde mevcut olacaktır.

Aslında bunu yapmak isteyeceğinizi sanmıyorum, çünkü commit'deki bir dosya değiştiğinde, commit'in hash'i de değişir.

Git dahili bileşenlerini kullanarak bunun neden zorlu bir problem olduğunu keşfetmeme izin verin. Mevcut commit'in sha1'ini şu şekilde alabilirsiniz:

#!/bin/bash
commit=$(git cat-file commit HEAD) #
sha1=($((printf "commit %s\0" $(echo "$commit" | wc -c); echo "$commit") | sha1sum))
echo ${sha1[0]}

Esasen, tarafından döndürülen iletide sha1 sağlama toplamı çalıştırırsınız git cat-file commit HEAD. Bu mesajı incelerken hemen iki şey sorun olarak ortaya çıkıyor. Biri sha1 ağacı ve ikincisi commit zamanı.

Artık taahhüt süresi, mesajı değiştirerek ve belirli bir zamanda bir taahhüt veya zamanlama yapmanın ne kadar sürdüğünü tahmin ederek kolayca halledilebilir. Asıl mesele, alabileceğiniz ağaç sha1'dir git ls-tree $(git write-tree) | git mktree. Esasen, tüm dosyaların ve sha1 sağlama toplamlarının bir listesi olan ls-ağacından gelen mesajda sha1 sağlama toplamı yapıyorsunuz.

Bu nedenle, sha1 sağlama toplamınız, çemberi tamamlayan ve sha1 kaydına bağlı olan sha1 sağlama toplamına doğrudan bağlı olan sha1 sağlama toplamınıza bağlıdır. Bu yüzden benim kullanabileceğim tekniklerle ilgili döngüsel bir probleminiz var.

Daha az güvenli sağlama toplamlarıyla , dosyanın sağlama toplamını kaba kuvvet yoluyla dosyanın kendisine yazmanın mümkün olduğu gösterilmiştir; ancak sha1 ile bu görevi yerine getiren herhangi bir çalışma bilmiyorum. Bu imkansız değil, ama şu anki anlayışımızla imkansızın yanında (ama kim bilir belki birkaç yıl içinde önemsiz olacak). Bununla birlikte, yine de, bir (blob) sağlama toplamının (ağaç) sağlama toplamının (commit) sağlama toplamını dosyaya yazmanız gerektiğinden, kaba kuvvet uygulamak daha da zordur.