![](/img/trans.png)
[英]Can I use meld to interactively review hunks for git add --patch
[英]How do I use a pager for long git add --patch hunks?
當我使用git add --patch
交互式添加diff
git add --patch
,有時會得到比屏幕長的塊,但無法使用less
來翻頁。
這對我來說很奇怪,因為我已經設置了:
[core]
pager = less -FRX --tabs=4
[pager]
diff = diff-highlight | less -FRX --tabs=4
interactive.diffFilter=
通過less
傳輸也無助於分頁。
我需要做什么才能讓git add--patch
使用less
以便我可以使用鍵盤來導航超過一個屏幕的任何輸出?
使用尋呼機的 Git 命令可以與任何通用stdin
尋呼機一起工作的原因是因為這種模型。 此類 git 命令將其輸出寫入stdout
。 尋呼機從stdin
讀取其輸入。 前者的stdout
通過管道傳送到后者的stdin
。 正是這種管道模型的簡單性使尋呼機具有通用性,並允許 git 允許您選擇自己的尋呼機,只要它使用此模型即可。
那么為什么git add -p
(或git add -i
)不能像git diff
或git log
呢?
git diff
和git log
不是交互式的。 git add -p
和尋呼機是交互式的。
管道模型的性質意味着一次只能控制一個應用程序,並且需要控制一個交互式應用程序。 為了讓尋呼機獲得對終端的控制(以便它可以顯示提示並響應您的輸入), git add -p
必須釋放控制權。 一旦發生,就無法收回。
這樣看:將有兩個命令行提示試圖與您交互:一個用於git add -p
,另一個用於尋呼機。 他們將如何協調? 它必須是這樣的:
git add -p
將一個大塊寫入stdout
,以及大塊結束 (EOH) 標記而不是通常的文件結束 (EOF) 標記。git add -p
然后將終端的控制權交給管道另一端的任何應用程序。quit
命令)時,它會退出。 但是 EOH 制造商告訴尋呼機,“不要退出。當用戶完成后,將控制權交還給上游應用程序。不要退出。等待。”quit
命令告訴它您已經像往常一樣完成了。git add
。git add
的終端提示然后將替換尋呼機的... 如您所見,這不僅是一種糟糕的用戶體驗(使用尋呼機的quit
命令在每個大塊上返回git add
),它還會完全破壞Unix 管道模型的強大功能和美感。
出於同樣的原因, git add -p
不能使用diff-so-fancy
git -p
具有類似尋呼機行為的唯一方法是內置一個,或者定義一個“Git Pager API”,然后我們等待人們編寫使用該 API 的尋呼機。 這是插件模型,它與管道模型非常不同。 這也意味着緊密集成: git add -p
命令和 pager 命令必須組合在一起,並在每個命令提示符下可用。
我發現在終端窗口中向上滾動很容易。 我的鍵盤命令允許我逐行或逐頁移動。
git add -p
的split
命令你有沒有考慮過使用git add -p
的split
命令來分解大塊頭? 無論如何,我發現較小的帥哥更容易推理!
作為一種解決方法,您可以設置EDITOR=less
並使用e
( edit
) 在大塊頭上運行less
。 但是,這種解決方法有一些缺點。 可以通過以下方式避免這些:
EDITOR="EDITOR='$EDITOR' bash -c 'set -m; less -K \"\$1\"' --" git add -p
重置EDITOR
調用之前less
允許使用標准v
鍵less
來調用編輯器。
less
的-K
選項允許使用 Control-C 退出less
,告訴 Git 不要暫存大塊。 用q
退出less
將導致大塊被上演。
set -m
創建一個單獨的進程組,阻止 Control-C 冒泡並殺死 Git 進程。
根據AtnNn 的回答,我想出了以下別名:
ap = !"VISUAL=\"VISUAL='$VISUAL' bash -c 'set -m; less -K -+F \\\"\\$1\\\"' --\" git add -p \"$@\" #"
e
以less
分頁大塊
^C
退出並重復交互菜單q
顯示顯示的內容v
編輯顯示的內容我正在做一個 PR 來在git
本身中解決這個問題。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.