2013-11-22 26 views

回答

0

實際上[email protected]{n}快捷爲一個提交對象。在我的回購協議,我這樣做:

git show [email protected]{1} 

AMD我得到這個:

commit 24774ab81ad6c8f0b071363f62bf438572a2b286 
Merge: 1c47ddf 31ae746 
Author: Roberto Bonvallet <[email protected]> 
Date: Fri Oct 18 13:15:44 2013 -0300 

因此,在這種情況下,[email protected]{0}24774ab81ad6c8f0b071363f62bf438572a2b286一個快捷方式。

2

實際上,手冊頁有一點點:你可以給任何「足夠存儲」的說明符。根據定義,實際儲藏參考,如stash[email protected]{3},總是「藏起來」。但是,任何通過$REV其中目標名稱 - 能夠:

  • $REV^2存在
  • $REV$REV^1$REV:$REV^1:$REV^2:都是語法分析

被認爲是一個藏匿處。冒號後綴變成提交ID成樹ID(確保它的存在),以及:

  • 藏匿本身是什麼ID $REV解析出到
  • 工作樹承諾是$REV
  • 「基地」承諾是$REV^1
  • 工作樹樹是$REV:
  • 基樹$REV^1:
  • 索引樹是01​​

如果$REV^3存在,則爲未跟蹤/忽略的文件提交,其樹爲$REV^3:

這是什麼意思是git stash會認爲任何「真正」的合併提交是一個藏匿處。 (但是,將它們當作st applying應用是最奇怪的。:-))

如果您希望能夠稍後用短名稱命名保存的存儲,則可以爲其指定另一個名稱,例如標記名稱:

git tag foo [email protected]{3} 

注意,此份[email protected]{3},而不是名稱:如果下一個推另一個藏匿,提交(現已被標記引用)將匹配[email protected]{4}。您可以通過使用git rev-parse看到這一點:

git rev-parse foo; git rev-parse [email protected]{3} 

將打印相同的巨人SHA-1值的兩倍,你藏起來一些新的東西,然後才:你藏別的東西后

git rev-parse foo; git rev-parse [email protected]{4} 

會做同樣的,推動另一個藏匿在「藏匿棧」。

您可以創建分支和標籤空間之外的名稱(或甚至外完全refs/)與git update-ref,和他們的工作:

git update-ref refs/jinkies/scooby stash 
git stash show jinkies/scooby 

,但我不推薦這種「手動」做,它太容易去這裏玩。使用標籤(並命名它們以便您可以記住它們的用途,如果您在編碼狂熱中編寫一堆數週或數月後遇到剩下的標籤)可能更明智。

相關問題