git günlüğündeki tüm etiketleri göster

Kayıt başına neden git log --decoratebirden fazla etiket gösterilmiyor?

DÜZENLEME : Charles Bailey cevabı buldu (en azından benim durumumda)
Esasen, işlemeye işaret eden başka bir etikete işaret eden bir etiketim vardı. Bu fazladan yönlendirme katmanı nedeniyle, etiket günlükte görünmüyordu. Bunu, etiketleme komut dosyamızı doğru etiketlemek için düzelterek veya etiketleri tekrar tekrar takip etmek için bazı kabuk komut dosyası voodoo'yu düzeltmek zorunda kalacağım. Her neyse, herhangi birinin istemesi durumunda bu soruyu sadece referans için bırakacağım. (Stack overflow konusunda yeniyim, ancak bunun doğru protokol olduğunu varsayıyorum?)

... Orijinal soru takip ediyor ...

Backstory: GIT'yi kaynak kontrolü için işte kullanıyoruz ve konuşlandırdığımızda her zaman bir commit etiketleme politikamız var. (Aslında etiketleri yapan ve ardından sunucuda etiketi çeken bir komut dosyasıdır). Ayrı hazırlama ve üretim sunucularına sahip bir web uygulaması olduğundan, genellikle bir sürümü hazırlama (test için veya her neyse) için etiketleriz ve daha sonra aynı kaydı üretim için etiketleriz.

Bu yüzden aslında aynı işlemede birden çok etiketimiz oluyor. Bunu metin günlüğünde görebilmek çok güzel olurdu, ancak bunu desteklemiyor gibi görünüyor. Şu anda aradığım etiketi manuel olarak kontrol ederek veya tetikleyerek sorunu çözmek için çalışıyorum gitk. Bu çözümlerin ikisi de işe yarasa da, bana öyle geliyor ki git log --decorate, varsayılan olarak kayıt başına yalnızca bir etiketi desteklemek gerçekten garip .

Biraz dolaştım ama pek bir şey bulamadım. Bariz bir şeyi mi kaçırıyorum?

Not (Aslında %dkılavuz sayfalarına ve bazı hızlı testlere göre özel bir format dizesi kullanıyorum , bunun karşılığı --decorate)

Charles Bailey'nin yorumda doğru bir şekilde belirttiği gibi, sorununun kaynağı olan etiket etiketi (bir etiketi etiketleme) hakkında not :

İmzalı bir etiketi geçersiz kılmak o kadar kolay olmadığından, bu ileti dizisini çalıştığınızdan emin olun :

• Zaten bir etiketi ittiyseniz, git tagman sayfası , basit git tag -f Bbir etiket adının " A" değiştirilmesini şiddetle tavsiye etti " "

• ile imzalanmış bir etiketi yeniden oluşturmayı denemeyin git tag -f(aşağıdaki iş parçacığı özetine bakın)

  (bir köşe vakası hakkındadır, ancak genel olarak etiketler hakkında oldukça öğreticidir ve başka bir SO katılımcısı Jakub Narębski'den gelmektedir ):

Lütfen etiket adının (ağır etiket, yani etiket nesnesi) iki yerde saklandığını unutmayın:

• etiket nesnesinin kendisinde 'etiket' başlığının içeriği olarak (bunu " git show <tag>" çıktısında ve ayrıca " " çıktısında görebilirsiniz git cat-file -p <tag>, burada <tag>ağır etikettir, örn v1.6.3. git.githavuzda),
• ve ayrıca refs/tags/*bir etiket nesnesine işaret eden varsayılan etiket referans adıdır (" " ad alanındaki referans ).
  Etiket referansının (" refs/tags/*" ad alanındaki uygun referans ) tamamen yerel konu olduğunu unutmayın; örneğin bir deponun ' refs/tags/v0.1.3' içinde, diğeri ' refs/tags/sub/v0.1.3' içinde olabilir .

Yani imzalı etiket oluşturduğunuzda ' A', aşağıdaki durumla karşılaşırsınız (bazı commit'leri işaret ettiğini varsayarak)

  35805ce   <--- 5b7b4ead  <=== refs/tags/A
  (commit)       tag A
                 (tag)

Lütfen " git tag -f A A" (onu açıklamalı bir etiket olmaya zorlayan seçeneklerin yokluğuna dikkat edin) bir noop olduğunu unutmayın - durumu değiştirmez.

Eğer "yaparsanız git tag -f -s A A": Eğer o notu kuvvete (git sen ne yaptığını biliyor varsayar böylece) bir etiket owerwriting ve bu bir -s/ -a/ -mseçenekler açıklamalı etiketi (tag nesnesinin yaratılması) zorlamak için kullanılır, alacağınız aşağıdaki durum

  35805ce   <--- 5b7b4ea  <--- ada8ddc  <=== refs/tags/A
  (commit)       tag A         tag A
                 (tag)         (tag)

Ayrıca " git show A" etiket olmayan nesneye kadar tüm zinciri gösterecektir ...

git log --no-walk --tags --pretty="%h %d %s" --decorate=full

Bu sürüm, commit mesajını da basacaktır:

 $ git log --no-walk --tags --pretty="%h %d %s" --decorate=full
3713f3f  (tag: refs/tags/1.0.0, tag: refs/tags/0.6.0, refs/remotes/origin/master, refs/heads/master) SP-144/ISP-177: Updating the package.json with 0.6.0 version and the README.md.
00a3762  (tag: refs/tags/0.5.0) ISP-144/ISP-205: Update logger to save files with optional port number if defined/passed: Version 0.5.0
d8db998  (tag: refs/tags/0.4.2) ISP-141/ISP-184/ISP-187: Fixing the bug when loading the app with Gulp and Grunt for 0.4.2
3652484  (tag: refs/tags/0.4.1) ISP-141/ISP-184: Missing the package.json and README.md updates with the 0.4.1 version
c55eee7  (tag: refs/tags/0.4.0) ISP-141/ISP-184/ISP-187: Updating the README.md file with the latest 1.3.0 version.
6963d0b  (tag: refs/tags/0.3.0) ISP-141/ISP-184: Add support for custom serializers: README update
4afdbbe  (tag: refs/tags/0.2.0) ISP-141/ISP-143/ISP-144: Fixing a bug with the creation of the logs
e1513f1  (tag: refs/tags/0.1.0) ISP-141/ISP-143: Betterr refactoring of the Loggers, no dependencies, self-configuration for missing settings.

Not: 5e1361c tamamlama gelen Brian m. carlson ( bk2204) (git 1.9 / 2.0 Q1 2014 için) etiketlerle günlük dekorasyonu açısından özel bir durumla ilgilenir:

günlük: zincirlenmiş etiketlerle süsleri doğru şekilde kullanın

git logbir etiket nesnesi artık ref olmayan başka bir etiket nesnesine başvurduğunda, örneğin ikinci etiketin silindiğinde, dekorasyonları doğru şekilde işlemedi .
Kaydetme parse_object, ikinci etikette çağrılmadığı ve bu nedenle etiketli alanı doldurulmadığı için doğru şekilde dekore edilmeyecekti, bu da etiketlerin hiçbirinin ilgili commit ile ilişkilendirilmemesine neden oluyordu.

parse_objectEtiket zincirinin referansı kaldırılabilmesi ve commit uygun şekilde dekore edilebilmesi için, yoksa bu alanı doldurmak için arayın .
Gelecekteki gerilemeleri önlemek için testleri de dahil edin.

Misal:

git tag -a tag1 -m tag1 &&
git tag -a tag2 -m tag2 tag1 &&
git tag -d tag1 &&
git commit --amend -m shorter &&
git log --no-walk --tags --pretty="%H %d" --decorate=full