: Gblame "u"바로 가기에서 현재 패치 제거

묘사

더 좋은 방법이 있을지도 모르지만 저는 아주 오래된 프로젝트를 처리하고 있습니다. 많은 작가들이 제출을 하고 있습니다(특히 오래된 svn-ish 제출, 1k+행 차이 사용git show HEAD~1000 | wc -l.
Gblame'd 함수:

ff1234
ff1234 function foo() {
44abc    if ( xyz == 999 ) {
44abc       alert(1);
44abc    }
ff1234 }
ff1234

나는 내가 '44abc' 를 내비게이션해서 'o' 를 누르면 차이를 열 수 있다는 것을 안다. (이것은 나에게 상하문 단서를 줄 수 있다.)나는 내가 441년 전에 그것의 수정판을 뉴스 전체에 입력했을 수도 있다는 것을 안다.그러나 때때로'감각'은'44abc'로 내비게이션하여'u'를 누르면 효과적이다.

git diff 44abc 44abc~1 SomeFile.js | patch && reload SomeFile.js

이상적인 상황에서 대체적인 커서 위치/같은 기능을 사용합니까?아마도 최근의 git hunk 제목 참고?(http://www.robertames.com/blog.cgi/entries/git-diff-hunk-headers-function-name.html) 시각적 선택이 필요할 수도 있다.
나는 이 점을 실현하기 위해 그럴듯한 알고리즘을 생각해 내려고 노력하고 있지만, 지금은 아무것도 없다.
기본적으로 '44abc' 가 단순히 조건 경보를 한 줄에서 세 줄로 나누고, 촉발 조건을 바꾸고, 컨트롤러에서 변경하는 것일 뿐인지 확인할 수 있다면 매우 유용할 것이다.경보 등에 기록...
감사합니다.

토론 #1

enter가 제출한 조상에서 서류를 다시 포장하는 대신 ~를 사용한다.이 파일을 작업 트리로 끌어올리려면 :Gwrite를 사용하고 :Gedit를 사용하여 작업 트리 버전으로 건너뜁니다.파일의 같은 위치로 이동하는 것 외에 이 모든 것을 완성할 수 있다는 것은 듣기에 매우 어렵다.정말 어려워요.
또는 enter를 사용하여 비교적 새로운 수정판을 열고 '오류' 창을 닫은 다음 :Gdiff ~ 을 누르십시오.(제가 방금 관련 버그를 복구했으니 먼저 당겨주세요.)이것은 지도에 봉할 가치가 있을 것이다.이제서야 나는 이 일이 생각났다.
내가 보통 하는 일은 o 상하문을 수동으로 찾는 것이다.만약 내가 간단한 방법을 찾아서 자동으로 적당한 상하문으로 옮길 수 있다면, 나는 할 수 있을 것이라고 생각한다.

토론 #2

나는 경기에서 정확한 위치로 뛰었다.게다가 b42215003c4955eae8f72fa14af7a371b6088e3 이 문제는 이미 해결되었다고 생각합니다!

토론 #셋

당신의 복구를 검사했습니다...나는'o'가 너를 제출이 발생하는 위치로 데리고 갈 수 있는 것을 좋아한다. 이것은 내가 처음으로'~'작업 흐름을 사용하거나 접촉한 것이다. 이것도 매우 좋다.
가난한 사람의'시각'차이에 대해 두 개의 분리에서':bp'와 같은 조작을 실행할 수 있는 방법이 있습니까? 그러면 제가 실행할 수 있습니다~~~rrr~r~r(w/-redo 부호일 수도 있습니다?).이것은 창고/역사 기록이 필요하기 때문에 가능할지 모르겠지만, 도움이 될 수 있습니다.
나는 또한 이 유대인 구홍을 시험해 보았는데 기본적인':Gblame'분할에 사용한다.

   :nmap <F2> 0ye<c-w>l:!git diff <c-r>"..<c-r>"^ -- <c-r>% \| patch -p1        [[[[<cr> ... if you're brave ;-)]]]]

...이것은 보기에 매우 추하다.전반적으로 패치가 실패할 수도 있지만, 커서 근처의 '패치 블록' 으로 제한하는 방법이 있다면, 패치는 내가 찾고 있는 보다 현지화된 역사 탐색에 점점 가까워질 것이다.
나는 또한 그것을 Gdiff와 결합시켜 약간 익살스러운 효과를 시도했다.

 :nmap <F2> 0ye<c-w>l:Gdiff <c-r>"<cr><c-w>h<c-w>h:q!<cr>

...그것은 논의된 차이에 대한 추가 버퍼를 열었지만, 효과가 좋지 않았다.
마지막으로 이 물건들의 조합을 흐트러뜨린 후에..."Gblame 창에서 다음 작업을 시도하십시오(""최적""작동 방법)."

:nmap <F2> o<c-w>p~

만약 'o' 창을 미리 보기로 표시한다면, 시간적으로 한 번 또 한 번 뒤로 물러설 때, 전체 '쌓기' 효과를 얻지 못할 것이다.(나는 로컬 복사본에서 일부 물건을 모의했지만, 나의vimscript 능력은 가장 많게는'meh'일 뿐이다. 그래서 나는 네가 직접 끌어내서 시험해 볼 수 있는 것을 얻을 수 없다.

1493,1494d1492 ... 'p' == "o, but in a preview window ... 'z' == try to repro that final macro by stringing together the "real" vimscript commands
<         nnoremap <buffer> <silent> p    :<C-U>exe <SID>BlameCommit((&splitbelow ? "botright" : "topleft")." pedit")<CR>
<         nnoremap <buffer> <silent> z    :<C-U>exe <SID>BlameCommit((&splitbelow ? "botright" : "topleft")." pedit")<CR> \| :<C-U>exe wincmd p \| :<C-U>exe <SID>BlameJump('~'.v:count1)<CR>
1521,1523d1518  ... this is right after the "execute cmd" line b/c preview window doesn't get focus by default
<   if a:cmd =~# 'pedit'
<     wincmd P
<   endif

최종적으로 몇 개의 '비뚤어진' w.r.t.가: Gblame 창에서 여러 개의 '~' 명령을 실행할 수 있을 것 같습니다.
어쨌든 관심 가져줘서 고마워요.나는 정말 이 용례를 발굴해서 그 안에 언급할 만한 것이 있는지, 아니면 그것이 결국 버려질지 보려고 노력하고 있다.

토론 #4

여기 많아요.나는 지금 부분만 대답하고 있다.
나는 p 지도를 좋아하지만, 지도가 몇 가지 문제를 제기했다.pedit 보통 초점을 원시 창에 두는데, 나는 이 의미를 보존하고 싶다.그러나 몇 줄의 다른 내용에서 진귀한 몇 줄의 미리 보기 창을 사용하는 것은 어리석은 것 같지만, 실제적으로 예상한 대로 사용할 수 있도록 사용자가 명확하게 초점을 맞춰야 한다.그럼 꼭대기까지 굴러가게 하는 거 아니에요?나는 이것이 나의 한 표라고 생각한다.
방주: git apply 대신 patch -p1를 사용한다.그것은 가장자리 사건을 처리하는 것이 더욱 우아하다.

토론 #5

'p'지도는 진정으로 하나의 단독 지도가 되고 싶은 것이 아니라 간단하게 당신의'정확한'o'지도를 밟지 않는 것이다.
나는 간단하게 'o' 창의 '표시' 를 미리 보기 창으로 하고, 자동 커서를 변경 위치로 이동하며, 사용자의 키보드 초점을 분할하는 행위를 유지하고, 미리 보기 창을 'o' 창처럼 '상당히 크다' 는 조치를 취하는 것을 권장한다.
즉,

     nnoremap <buffer> <silent> o    :<C-U>exe <SID>BlameCommit((&splitbelow ? "botright" : "topleft")." pedit")<CR>
     ...
     if a:cmd =~# 'pedit'
       wincmd P
       wincmd +
       wincmd +
       wincmd +
       wincmd +
       wincmd +
     endif

나는 99퍼센트가 현재의'o'와 같은 의미를 유지한다고 생각한다. 왜냐하면 이것은 더욱'편안한'행위이기 때문이다.나에게 있어서'o'는 매우 쓰기 좋지만,'o를 쌓아올리는 생각'은 거의 네가 원하는 것이 아니다.어쩌면 네가 옳을지도 몰라..."'o'는 진정한 창이고'p'는'o'이지만 미리보기 창에서 매크로는 p~p~p~...로 퇴화되어 시간을 직관적으로 되돌린다.
어떤 상황에서도 코드 '원형' 으로 이 맵을 시도하기만 하면, 왜 내가 'o' 창을 '진실' 창이 아닌 미리보기 창으로 바꾸기 시작했는지 알게 될 것이다.

:nmap <F2> o<c-w>p~

...이것은 커서 아래에서 diff를 열고 +/- 모두 밝게 표시하며 ~ 코드 부분을'diff 기간의 모습'으로 다시 포장합니다.
문제는 이 매크로를 여러 번 두드리면 'o' 윈도우즈 창고에 있는 b/c의 사용이 점점 줄어들 것이다.그러나 만약 새로운 가상의 'p' 명령을 사용한다면, 'o' 창은 기본적으로 바뀔 것이다. 나는 이것이 거의 항상 네가 원하는 행동이라고 생각한다.
사실, 나는 네가 나를 설득하고 있다고 생각한다...o == as-isp == o but in a preview window(Gblame 창에 커서를 두지만 시각적으로'o'와 같은 조작을 수행함)도 있을 수 있다! == p~.나는 이것이 처리할 수 있는 문제/행위라고 생각한다. 내가 해결해야 한다. 나는 내가 패치/당기기 요청을 받을 수 있는지 확인하고 그것을 당신에게 보낼 것이다.