如何使用 git describe 匹配隱藏的 ref

Question

從 git 存儲庫派生版本號似乎是匹配版本號的一個很好的解決方案，但我的情況有點不同。

我生成的版本號我想為其創建隱藏的引用（因此默認情況下它們不會傳遞給其他客戶端）。 我不希望客戶在他們的獲取中看到一堆版本流失。

問題是， --match 僅適用於標簽，即使您使用 --all 標志。

例子：

git update-ref refs/_v.master.0.1 c2897c8338e02b99644640f3afb829c04cb48439

這將創建隱藏的參考

git describe --all c2897c8338e02b99644640f3afb829c04cb48439
_v.master.0.1 [顯示出來]

但這不會返回任何內容：

git 描述 --match _v* --all c2897c8338e02b99644640f3afb829c04cb48439
致命：未找到名稱，無法描述任何內容。

我在文檔中看到 --match “只考慮匹配給定 glob(7) 模式的標簽”，但這似乎很蹩腳，匹配應該適用於任何 ref 類型，假設其他修飾符（-all --tags 等）限制引用類型的范圍。

我還有其他方法可以做到這一點嗎？ 我想到的一種方法是在一個客戶端上創建標簽，並將它們（在推送和獲取時間）映射到來自/來自源的隱藏引用，但這似乎需要很多額外的工作。 如果不是客戶端，我上面提到的 ref 匹配是否可以從 API 獲得？

提前致謝！

Answer 1

您必須使用 Git 2.14.x/2.15（2017 年第四季度）進行檢查

“ git describe --match <pattern> ”已被教導與“ --all ”選項配合得很好。

請參閱Max Kirillov ( max630 ) 提交的 6d68b2a （2017 年 9 月 20 日） 。
^{（由Junio C gitster合並gitster 提交 8c1bc7c ，2017 年 9 月 29 日）}

describe : 教--match處理分支和遙控器

當git describe使用--match ，它只匹配標簽，基本上忽略--all參數，即使它被指定。

通過匹配分支名稱和$remote_name/$remote_branch_name來修復它，用於遠程跟蹤引用，具有指定的模式。
相應地更新文檔並添加測試。

它還處理負面模式：

例如，假設您希望找到包含某個提交的第一個官方發布標簽。 如果我們假設官方發布標簽的形式為“ v* ”，並且預發布候選的名稱中包含“ *rc* ”，我們現在可以找到第一個引入提交abcdef發布標簽：

git describe --contains --match="v*" --exclude="*rc*" abcd

---

請注意，Git 2.16.x/2.17（2018 年第一季度）將為“ git describe --all ”恢復正確的輸出。
請參閱Daniel Knittl-Frank ( knittl ) 的commit 1bba001 （2017 年 12 月 11 日） 。
^{（由Junio C gitster合並-- gitster -- in commit fac64e0 ，2018 年 1 月 23 日）}

describe : 在描述帶有嵌入名稱的標簽時，在前面加上“ tags/ ”

“ git describe ”命令的手冊頁解釋了使用--all選項時的預期輸出，即顯示完整的參考路徑，包括heads/或tags/前綴。

當212945d （“Teach git-describe to verify annotated tag names before output”，2008 年 2 月 28 日，Git v1.5.5-rc0）使 Git 偏愛帶注釋的標簽的嵌入名稱時，它不小心更改了輸出格式時--all給出了標志，只打印沒有前綴的標簽名稱。

檢查是否指定了--all並為此特殊情況重新添加“ tags/ ”前綴以修復回歸。

---

當“ git describe C ”發現帶有標記名A的注釋標記是解釋提交C的最佳名稱，並且該標記存儲在refs/tags層次結構中的“ wrong ”位置時，例如refs/tags/B ，命令給出了警告信息，但使用A （不是B ）來描述C 。
如果C正好在標簽上，則描述輸出將是“ A ”，但“ git rev-parse A^0 ”將不等於“ git rev-parse C^0 ”。

該命令的行為已在 Git 2.27（2020 年第 2 季度）中進行了更改，以使用“長”形式，即A-0-gOBJECTNAME ，由rev-parse正確解釋。

請參閱Junio C gitster ( gitster ) 提交的 ff165f0 （2020 年 2 月 20 日） 。
^{（由Junio C gitster合並-- gitster -- in commit 0f0625a ，2020 年 3 月 27 日）}

describe ：基於錯誤定位的標簽強制使用長格式的名稱

^{幫助：馬修斯·塔瓦雷斯
幫助：傑夫·金}

帶注釋的標簽有兩個名稱：

• 它位於refs/tags層次結構中的位置和
• 記錄在對象本身的“ tag ”字段中的tag 。

它們通常應該匹配。

自212945d4 （“Teach git describe to verify annotated tag names before output”, 2008-02-28, Git v1.5.5-rc0 -- merge ）以來，使用帶注釋的標簽描述的提交將其名稱基於對象的標記名。

雖然這是一個深思熟慮的設計決定，目的是讓與他人更容易地談論標簽，即使標簽碰巧被提取到與其創建者給的名稱不同的名稱，它也有一個缺點。

“ git describe ”的輸出，至少在現代 Git 中，應該可以用作對象名稱來命名給“ git describe ”命令的確切提交。

在描述由此類標記直接指向的提交時，當兩個名稱不同時，使用標記名會破壞此屬性。

注釋標簽 Bob 制作為“ v1.0 ”可能位於ref層次結構中的“ refs/tags/v1.0-bob ”，並且“ git describe v1.0-bob^0 ”的輸出會說“ v1.0 ”，但“ refs/tags/v1.0 ”本地可能沒有任何標簽，或者可能有另一個標簽指向不同的對象。

請注意，如果所描述的提交不是由此類錯誤定位的標簽直接指向的，則這不會成為問題。

在上一段的示例中，描述父項為v1.0-bob的提交將導致“ v1.0 ”（即取自標記對象的標記名）后跟“ -1-gXXXXX ”，其中XXXXX是縮寫對象名，以“ -g ”結尾的字符串是十六進制字符串開頭的對象的對象名（只要是唯一的），所以前導部分是否為“ v1.0 ”或“ v1.0-bob ”。

以長格式顯示名稱，即帶有“ -0-gXXXXX ”后綴，當我們給出的名稱是基於錯誤定位的注釋標簽時，以確保輸出可以用作最初提供給命令的對象的對象名稱解決問題。

在此過程中，刪除過於謹慎的死代碼以防止沒有標記名的帶注釋的標記對象。

這樣的標記在代碼流中更早地被過濾掉，並且不會到達代碼的這部分。