git-push（1）手冊頁
目錄位置：git安裝位置/Git/mingw64/share/doc/git-doc/git-push.html 谷歌翻譯了一下
名稱
git-push-更新遠程引用以及相關對象
概要
git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
[-u | --set-upstream] [--push-option=<string>]
[--[no-]signed|--signed=(true|false|if-asked)]
[--force-with-lease[=<refname>[:<expect>]]]
[--no-verify] [<repository> [<refspec>…]]
描述
使用本地引用更新遠程引用，同時發送完成給定引用所需的對象。
每次通過建立 hooks ,向存倉庫推送代碼時，都可以使它發生有趣的事情。請參閱git-receive-pack（1）的文檔。
當命令行未使用<repository>參數指定將信息推送到何處時，將參考當前分支的 branch.*.remote 配置來確定將信息推送到何處。如果缺少配置，則默認為origin。
當在命令行中沒有使用<refspec>參數或--all，--mirror，--tags選項來指定推送內容，該命令將通過參照 remote.*.push 配置來查找默認的<refspec>，如果沒有找到它，push.default配置決定推送內容（見git-config為（1）中 push.default 的含義）。
當命令行和配置均未指定要推送的內容時，將使用默認行為，該行為對應於push.default 的 simple 值：當前分支被推送到相應的上游分支，但是作為安全措施，如果上游分支與本地分支的名稱不同，將取消推送。
選項
<repository>
作為推送操作目標的“遠程”repository。此參數可以是URL（請參閱下面的GIT URLS部分）或遙控器的名稱（請參見下面的REMOTES部分）。
<refspec> ...
指定要使用哪個源對象更新的目標引用。<refspec>參數的格式是可選的plus +，其后是源對象<src>，然后是冒號:，然后是目標ref <dst>。
<src>通常是您要推送的分支的名稱，但它可以是任意的“ SHA-1表達式”，例如master~4或 HEAD（請參見gitrevisions（7））。
<dst>告知通過此推送更新遠程端的哪個引用。此處不能使用任意表達式，必須命名實際引用。如果git push [<repository>]未<refspec>設置任何參數以<src>使用 remote.<repository>.push配置變量更新目標處的某些引用，:<dst>則可以省略part-這樣的推送將更新<src>通常<refspec>在命令行上沒有任何更新的引用。否則，缺少 :<dst>表示要更新與相同的ref <src>。
<src>引用的對象用於更新遠程端的<dst>引用。默認情況下，僅當<dst>不是標記（帶注釋或輕量級）時才允許，然后僅當它可以快速轉發<dst>時才允許。通過具有可選的領導+，你可以讓Git更新<DST> REF即使是默認不允許的（比如，它不是一個快進。）這並不會試圖合並<來源>為<DST> 。有關詳細信息，請參見下面的示例。
tag <tag>的含義與相同refs/tags/<tag>:refs/tags/<tag>。
推送空的<src>允許您從遠程repository中刪除<dst>引用。
特殊的refspec :（或+:允許進行非快速更新）指示Git推送“匹配”分支：對於本地存在的每個分支，如果遠程上已經存在同名分支，則更新遠程端側。
--all
推送所有分支（即ref下的ref refs/heads/）；不能與其他<refspec>一起使用。
--prune
刪除沒有本地副本的遠程分支。例如，tmp如果不再存在具有相同名稱的本地分支，則將刪除遠程分支。這也遵守refspecs，例如 git push --prune remote refs/heads/*:refs/tmp/*，確保 不存在的遠程對象refs/tmp/foo將被刪除refs/heads/foo。
--mirror
代替命名每個ref推的，則指定下的所有參考文獻refs/（包括但不限於refs/heads/，refs/remotes/和refs/tags/）被鏡像到遠程repository。新創建的本地ref將被推送到遠程端，本地更新的ref將在遠程端強制更新，而已刪除的ref將從遠程端刪除。如果remote.<remote>.mirror設置了配置選項，則這是默認設置。
-n
--dry-run
除了實際發送更新外，執行所有其他操作。
-- porcelain
產生機器可讀的輸出。每個引用的輸出狀態行將以制表符分隔，並發送到stdout而不是stderr。將給出參考的完整符號名稱。
--delete
從遠程repository中刪除所有列出的參考。這與在所有引用之前加冒號相同。
--tags
refs/tags除了在命令行上明確列出的refspecs外，還將推送下面的所有refs 。
--follow-tags
推送所有不帶此選項將被推送的引用，並推送帶注釋的標簽，refs/tags這些標簽從遠程丟失，但指向被推送的引用可到達的提交。也可以使用配置變量指定push.followTags。有關詳細信息，請參見push.followTags在GIT-配置（1）。
--[no-]signed
--signed=(true|false|if-asked)
GPG對推送請求進行簽名，以更新接收方的ref，以使其可以通過掛鈎進行檢查和/或記錄。如果false或--no-signed，則不會嘗試簽名。如果true或--signed，則如果服務器不支持簽名的推送，則推送將失敗。如果設置為if-asked，則僅當服務器支持簽名的推送時才簽名。如果實際調用失敗，則推送也將gpg --sign失敗。有關接收端的詳細信息，請參見 git-receive-pack（1）。
--[no-]atomic
如果可用，請在遠程使用原子事務。所有參考均已更新，或者如果出錯，則不會更新任何參考。如果服務器不支持原子推送，則推送將失敗。
-o
--push-option
將給定的字符串傳輸到服務器，服務器將它們傳遞到接收前和接收后鈎子。給定的字符串不得包含NUL或LF字符。
--receive-pack=<git-receive-pack>
--exec=<git-receive-pack>
遠端git-receive-pack程序的路徑。通過ssh推送到遠程repository時，有時會很有用，並且您的程序沒有位於默認$ PATH的目錄中。
--[no-]force-with-lease
--force-with-lease=<refname>
--force-with-lease=<refname>:<expect>
通常，“ git push”拒絕更新不是用於覆蓋它的本地引用的祖先的遠程引用。
如果遠程引用的當前值是期望值，則此選項將覆蓋此限制。否則“ git push”將失敗。
想象一下，您必須重新整理已經發布的內容。您必須繞過“必須快速轉發”規則，才能用重新設置的歷史記錄替換最初發布的歷史記錄。如果您在重新定居時有其他人建立在您的原始歷史之上，則遠程分支的尖端可能隨着她的提交而前進，而盲目地推動--force將失去她的工作。
使用此選項，您可以說您希望更新的歷史記錄是您要重新定位並希望替換的歷史記錄。如果遠程引用仍然指向您指定的提交，則可以確保沒有其他人對引用進行任何操作。就像對引用進行“租賃”而不顯式鎖定它一樣，並且僅當“租賃”仍然有效時才更新遠程引用。
--force-with-lease 僅通過在不指定詳細信息的情況下，就可以通過要求其當前值與我們為它們提供的遠程跟蹤分支的值相同來保護所有將要更新的遠程引用。
--force-with-lease=<refname>，而無需指定期望值，將通過要求其當前值與我們擁有的遠程跟蹤分支相同，來保護命名的ref（單獨）（如果要更新）。
--force-with-lease=<refname>:<expect>如果要更新命名的ref（如果要更新），則將要求其當前值與指定值相同<expect>（允許與我們為refname提供的遠程跟蹤分支不同），從而保護它（單獨）使用此表單時，我們甚至不必擁有這樣的遠程跟蹤分支。如果<expect>為空字符串，則命名引用必須不存在。
請注意，除此形式以外，所有其他形式都--force-with-lease=<refname>:<expect> 明確指定了ref的預期當前值，這些形式仍處於實驗階段，隨着我們對該功能的經驗積累，它們的語義可能會發生變化。
“ --no-force-with-lease”將取消命令行上所有以前的--force-with-lease。
關於安全性的一般說明：提供此選項時沒有期望的值，即 與隱式運行在遙控器上並在后台（例如 ，在cronjob中的repository中）隱式運行的任何內容--force-with-lease或--force-with-lease=<refname>與之交互作用非常差。git fetchgit fetch origin
它提供的保護措施可以--force確保您的工作所基於的后續更改不會被破壞，但是如果某些后台進程在后台更新引用，這將是微不足道的。除了遠程跟蹤信息以外，我們沒有其他任何信息，可以啟發您希望看到的參考文獻，並願意為之煩惱。
如果您的編輯器或其他系統正在git fetch后台運行，那么減輕此問題的一種方法就是簡單地設置另一個遙控器：
git remote add origin-push $（git config remote.origin.url）
git fetch origin-push
現在，當后台進程運行時git fetch origin，引用origin-push不會更新，因此命令如下：
git push --force-with-lease origin-push
除非您手動運行，否則將失敗git fetch origin-push。當然，此方法被運行的東西完全擊敗了git fetch --all，在這種情況下，您需要禁用它或做一些更單調的事情：
git fetch＃從遠程更新'master'
git tag base master＃標記我們的基點
git rebase -i master＃重寫一些提交
git push --force-with-lease = master：base master：master
也就是說base，為您已經看到並願意覆蓋的上游代碼版本創建標簽，然后重寫歷史記錄，最后master如果遠程版本仍位於base，則 強制將更改推送到，而不管您本地中的本地版本remotes/origin/master已更新為什么。背景。
-f
--force
通常，該命令拒絕更新不是用於覆蓋它的本地引用的祖先的遠程引用。同樣，當使用--force-with-leaseoption 時，命令拒絕更新其當前值與預期值不匹配的遠程引用。
該標志禁用這些檢查，並可能導致遠程repository丟失提交。小心使用。
請注意，這--force適用於所有推送的ref，因此在push.default設置為matching或配置了多個推送目標的情況下使用它remote.*.push可能會覆蓋當前分支以外的其他ref（包括嚴格位於其遠程副本后面的本地ref）。要僅將一個推送強制到一個分支，請+在refspec前面使用a 進行推送（例如git push origin +master，強制推送到該master分支）。有關<refspec>...詳細信息，請參見上面的 部分。
--repo = <repository>
此選項等效於<repository>參數。如果兩者都指定，則命令行參數優先。
-u
--set-upstream
對於每個最新的或成功推送的分支，請添加上游（跟蹤）引用，該引用由無參數 git-pull（1）和其他命令使用。有關詳細信息，請參見branch.<name>.merge在GIT-配置（1）。
--[no-]thin
這些選項被傳遞給git-send-pack（1）。當發送方和接收方共享許多相同的對象時，精簡傳輸會大大減少發送的數據量。默認值為\-thin。
-q
--quiet
禁止所有輸出，包括更新的引用列表，除非發生錯誤。進展不會報告給標准錯誤流。
-v
--verbose
詳細地運行。
--progress
除非指定了-q，否則默認情況下，將狀態錯誤報告到標准錯誤流時，將在標准錯誤流上報告該狀態。即使標准錯誤流未定向到終端，該標志也會強制顯示進度狀態。
--no-recurse-submodules
--recurse-submodules=check|on-demand|only|no
可用於確保要推送的修訂所使用的所有子模塊提交在遠程跟蹤分支上均可用。如果使用check，則Git將驗證至少要在子模塊的一個遠程上可用的所有要在修訂版本中進行更改的子模塊提交都可用。如果缺少任何提交，則推送將被中止並以非零狀態退出。如果按需使用，則將推送要推送的修訂中已更改的所有子模塊。如果按需無法推送所有必要的修訂，它將也被中止並以非零狀態退出。如果僅使用該選項，則在不按下超級項目的情況下將遞歸推送所有子模塊。否或使用的值--no-recurse-submodules 當不需要子模塊遞歸時，可用於覆蓋push.recurseSubmodules配置變量。
--[no-]verify
撥動預推鈎（請參閱githooks（5））。默認值為--verify，為掛鈎提供了阻止推送的機會。使用--no-verify，掛鈎將被完全繞過。
-4
--ipv4
僅使用IPv4地址，忽略IPv6地址。
-6
--ipv6
僅使用IPv6地址，而忽略IPv4地址。
GIT URLS
通常，URL包含有關傳輸協議，遠程服務器的地址以及repository路徑的信息。根據傳輸協議，某些信息可能不存在。
Git支持ssh，git，http和https協議（此外，可以使用ftp和ftps進行獲取，但這效率低下且不建議使用；請勿使用它）。
本機傳輸（即git：// URL）不進行身份驗證，在不安全的網絡上應謹慎使用。
以下語法可以與它們一起使用：
ssh：// [user @] host.xz [：port] /path/to/repo.git/
git：//host.xz [：port] /path/to/repo.git/
http [s]：//host.xz [：port] /path/to/repo.git/
ftp [s]：//host.xz [：port] /path/to/repo.git/
ssh協議也可以使用類似scp的語法：
[user @] host.xz：path / to / repo.git /
僅當第一個冒號前沒有斜杠時，才識別此語法。這有助於區分包含冒號的本地路徑。例如，foo:bar可以將本地路徑指定為絕對路徑，或./foo:bar避免被誤解為ssh url。
ssh和git協議還支持〜username擴展：
ssh：// [user @] host.xz [：port] /〜[user] /path/to/repo.git/
git：//host.xz [：port] /〜[user] /path/to/repo.git/
[user @] host.xz：/〜[user] /path/to/repo.git/
對於本地repository（Git本身也支持），可以使用以下語法：
/path/to/repo.git/
文件：///path/to/repo.git/
這兩種語法幾乎是等效的，除了在克隆時（前者暗示--local選項時）。有關詳細信息，請參見git-clone（1）。
當Git不知道如何處理某種傳輸協議時，它將嘗試使用remote- <transport>遠程幫助程序（如果存在）。要顯式請求遠程幫助者，可以使用以下語法：
<運輸> :: <地址>
其中，<地址>可以是路徑，服務器和路徑，也可以是被調用的特定遠程幫助程序識別的類似於URL的任意字符串。有關詳細信息，請參見gitremote-helpers（1）。
如果存在大量類似名稱的遠程repository，並且您想為它們使用不同的格式（這樣，您使用的URL將被重寫為有效的URL），則可以創建以下形式的配置部分：
[url "<actual url base>"] insteadOf = <other url base>
例如，與此：
[url "git://git.host.xz/"] insteadOf = host.xz:/path/to/ insteadOf = work:
諸如“ work：repo.git”或“ host.xz：/path/to/repo.git”之類的URL將在任何將URL為“ git：//git.host.xz/repo”的上下文中重寫.git”。
如果您只想重寫用於推送的URL，則可以創建以下形式的配置部分：
[url "<actual url base>"] pushInsteadOf = <other url base>
例如，與此：
[url "ssh://example.org/"] pushInsteadOf = git://example.org/
像“ git：//example.org/path/to/repo.git”之類的網址將被重寫為“ ssh：//example.org/path/to/repo.git”以進行推送，但是pull仍將使用原始網址。
遠程 REMOTES
可以使用以下任一名稱代替URL作為<repository>參數：
在GIT中的配置文件中的遠程：$GIT_DIR/config，
目錄中的$GIT_DIR/remotes文件，或
目錄中的$GIT_DIR/branches文件。
所有這些還允許您從命令行省略refspec，因為它們每個都包含git默認情況下將使用的refspec。
在配置文件中命名為remote
您可以選擇提供以前使用git-remote（1），git-config（1）甚至通過手動編輯$GIT_DIR/config文件配置的遠程名稱。該遙控器的URL將用於訪問repository。如果您未在命令行上提供refspec，則默認情況下將使用此遙控器的refspec。配置文件中的條目將如下所示：
[remote "<name>"] url = <url> pushurl = <pushurl> push = <refspec> fetch = <refspec>
將<pushurl>僅用於推動。它是可選的，默認為<url>。
$GIT_DIR/remotes 中的命名文件
您可以選擇在中提供文件名$GIT_DIR/remotes。該文件中的URL將用於訪問repository。如果未在命令行上提供refspec，則此文件中的refspec將用作默認值。該文件應具有以下格式：
URL: one of the above URL format Push: <refspec> Pull: <refspec>
Push:線被用於通過GIT中推和 Pull:線通過使用GIT中拉和GIT取。可以為其他分支映射指定多行Push:和多Pull:行。
$GIT_DIR/branches 中的命名文件
您可以選擇在中提供文件名$GIT_DIR/branches。該文件中的URL將用於訪問repository。該文件應具有以下格式：
<url>＃<head>
<url>是必須的; #<head>是可選的。
如果您沒有在命令行上提供refspec，則git將使用以下refspec之一，具體取決於操作。 <branch>這個文件中的名稱$GIT_DIR/branches和 <head>默認master。
git fetch使用：
refs/heads/<head>:refs/heads/<branch>
git push用途：
HEAD：refs / heads / <head>
輸出
“ git push”的輸出取決於所使用的傳輸方法。本節介紹了推送Git協議時（本地或通過ssh）的輸出。
推送狀態以表格形式輸出，每行代表一個引用的狀態。每行的格式為：
<flag> <summary> <from> -> <to> (<reason>)
如果使用--porcelain，則輸出的每一行均采用以下格式：
<flag> \t <from>:<to> \t <summary> (<reason>)
僅當使用--porcelain或--verbose選項時，才會顯示最新引用的狀態。
flag
指示參考狀態的單個字符：
(space)
成功推動快速前進；
+
成功進行強制更新；
-
對於成功刪除的引用；
*
成功推送新ref；
!
對於被拒絕或無法推送的ref；和
=
對於最新的ref，不需要推送。
summary
對於成功推送的ref，摘要以適合用作參數的形式顯示了ref的舊值和新值 git log（<old>..<new>在大多數情況下， 這是<old>...<new>強制性的非快進更新）。
對於失敗的更新，將給出更多詳細信息：
rejected
Git根本沒有嘗試發送引用，這通常是因為它不是快速轉發的，並且您沒有強制執行更新。
遠程拒絕
遠端拒絕更新。通常是由遠程側的鈎子引起的，或者是由於遠程repository具有以下有效的安全選項之一：（ receive.denyCurrentBranch用於推送到檢出的分支），receive.denyNonFastForwards（用於強制性非快進更新）receive.denyDeletes或 receive.denyDeleteCurrent。請參閱git-config（1）。
遠程故障
遠程端未報告對引用的成功更新，可能是由於遠程端的臨時錯誤，網絡連接中斷或其他臨時錯誤。
from
被推送的本地引用的名稱，減去其 refs/<type>/前綴。在刪除的情況下，將省略本地引用的名稱。
to
要更新的遠程引用的名稱，減去其 refs/<type>/前綴。
reason
易於理解的解釋。在成功推入ref的情況下，不需要解釋。對於失敗的參考，將描述失敗的原因。
關於快進的注意事項
當更新將用於指向提交A的分支（或更通常為ref）更改為指向另一個提交B的分支時，當且僅當B是A的后代時，才稱為快進更新。
在從A到B的快進更新中，原始提交A建立在其之上的提交集合是新提交B建立在其之上的提交的子集。因此，它不會丟失任何歷史記錄。
相反，非快速更新將丟失歷史記錄。例如，假設您和其他人從同一提交X開始，並且您建立了一個導致提交B的歷史記錄，而另一個人建立了一個導致提交A的歷史記錄。歷史記錄如下所示：
B
/
--- X --- A
進一步假設其他人已經將導致A的更改推回到原始repository，您從中獲得兩個原始提交X。
另一個人進行的推送將以前指向提交X的分支更新為指向提交A的分支。這是一個快進操作。
但是，如果您嘗試推送，則將嘗試使用提交B更新分支（現在指向A）。這不能快進。如果這樣做，則提交A引入的更改將丟失，因為現在每個人都將開始在B的基礎上進行構建。
默認情況下，該命令不允許進行不是快進的更新，以防止此類歷史記錄丟失。
如果您不想丟失工作（從X到B的歷史記錄）或其他人的工作（從X到A的歷史記錄），則需要首先從repository中獲取歷史記錄，創建包含已完成更改的歷史記錄雙方，並將結果推回去。
您可以執行“ git pull”，解決潛在的沖突，並“ git push”結果。“ git pull”將在提交A和B之間創建合並提交C。
B---C
/ /
--- X --- A
使用生成的合並提交更新A將快速進行，並且您的推送將被接受。
或者，您可以使用“ git pull --rebase”在A之上的X和B之間重新設置更改，並將結果推回去。重新設置基礎將創建一個新的提交D，該提交將在A的頂部建立X和B之間的更改。
B D
/ /
--- X --- A
同樣，使用此提交更新A將快速進行，您的推送將被接受。
還有另一種常見情況，當您嘗試推送時，您可能會遇到非快進拒絕，即使您將其推送到其他人都沒有推送到的repository中也是有可能的。自己推送提交A之后（在本節的第一張圖片中），將其替換為“ git commit --amend”以生成提交B，然后嘗試將其推出，因為忘記了您已經將A退出了。在這種情況下，並且僅當您確定在此期間沒有人提取了較早的提交A（並開始在其上構建）時，才可以運行“ git push --force”來覆蓋它。換句話說，“ git push --force”是一種保留方法，用於您確實要失去歷史記錄的情況。
例子
git push
像一樣工作git push <remote>，其中<remote>是當前分支的遠程（或origin，如果當前分支未配置任何遠程）。
git push origin
如果沒有其他配置，remote.origin.merge則將其與當前分支的名稱相同，將當前分支推送到已配置的上游（配置變量），並且在不進行推送的情況下出錯。
如果未指定<refspec>，則可以通過設置push遙控器的選項或push.default 配置變量來配置此命令的默認行為。
例如，默認為僅推送當前分支以origin 使用git config remote.origin.push HEAD。可以將任何有效的<refspec>（如以下示例中的那些）配置為的默認值 git push origin。
git push origin :
將“匹配”分支推至origin。有關“匹配”分支的說明，請參見上面“ 選項”部分中的<refspec> 。
git push origin master
master在源repository中找到匹配的引用（很可能會找到refs/heads/master），並使用它更新repository中的相同引用（例如refs/heads/master）origin。如果master不存在，則將創建它。
git push origin HEAD
一種方便的方式將當前分支推到遠程上的相同名稱。
git push mothership master:satellite/master dev:satellite/dev
使用匹配master（例如refs/heads/master）的源ref 更新satellite/master（最可能是 refs/remotes/satellite/master）mothershiprepository中匹配的ref ；對dev和做同樣的事情satellite/dev。
這是為了模擬在相反方向git fetch上運行的mothership使用情況git push，以集成完成的工作satellite，並且在您只能以一種方式建立連接時（例如，衛星可以切換為母艦但母艦無法啟動與衛星，因為后者位於防火牆后面或未運行sshd）。
運行此之后git push的上satellite機，你會通過SSH進入mothership和運行git merge那里完成的仿真git pull是被上運行mothership，以拉動變化上進行satellite。
git push origin HEAD:master
按當前分支到遠程REF匹配master的 originrepository。這種形式可以方便地推送當前分支，而無需考慮其本地名稱。
git push origin master:refs/heads/experimental
通過復制當前分支experimental在originrepository中創建master分支。僅當本地名稱和遠程名稱不同時，才需要使用此表單在遠程repository中創建新的分支或標記。否則，引用名稱本身將起作用。
git push origin :experimental
experimental在originrepository中找到匹配的參考（例如refs/heads/experimental），然后將其刪除。
git push origin +dev:master
使用dev分支更新原始repository的master分支，從而允許非快速更新。 這可能會使未引用的提交懸在原始repository中。 請考慮以下情況，其中不可能實現快進：
o --- o --- o --- A --- B起源/母版
\
X --- Y --- Z dev
上面的命令會將原始repository更改為
A --- B（未命名的分支）
/
o --- o --- o --- X --- Y --- Z主
提交A和B將不再屬於具有符號名稱的分支，因此將不可訪問。這樣，這些提交將被git gc源repository上的命令刪除。
安全
提取和推送協議的目的不是防止一方從另一不打算共享的repository中竊取數據。如果您需要保護私人數據免受惡意對等，最好的選擇是將其存儲在另一個repository中。這適用於客戶端和服務器。特別是，服務器上的名稱空間對於讀取訪問控制無效。您只應向對整個repository具有讀訪問權限的客戶機授予對名稱空間的讀訪問權限。
已知的攻擊媒介如下：
受害者發送“ have”行，廣告它擁有的對象的ID，這些對象的ID並不是明確要共享的，但是如果對等體也有它們，則可以用來優化傳輸。攻擊者選擇要竊取的對象ID X並將引用發送給X，但由於受害者已經擁有X，因此不需要發送X的內容。現在，受害者認為攻擊者擁有X，並將X的內容稍后發送回攻擊者。（通過在客戶端有權訪問的命名空間中創建對X的引用，然后將其提取，這種攻擊對於客戶端在服務器上執行是最直接的。服務器在客戶端上執行此操作的最可能方式是“將“ X”合並到公共分支，並希望用戶在該分支上做其他工作並將其推送回服務器，而不會注意到合並。）
與＃1一樣，攻擊者選擇要竊取的對象IDX。受害者發送攻擊者已經擁有的對象Y，並且攻擊者錯誤地聲稱擁有X而不是Y，因此受害者將Y作為對X的增量發送。該增量向攻擊者揭示了與Y相似的X區域。