'O'상태 창에서 사용자에게 의외로 머리를 고쳐 달라고 요청(was: 도주범이 내 머리를 먹었다)

묘사

병원체와 도주범을 나의vim환경에 설치한다.
파일을 편집했습니다.
이동: Gcommit.커밋 실패. 오류는 다음과 같습니다.
오류: 인용 헤더를 해석할 수 없습니다: 이런 파일이나 디렉터리가 없습니다
치명적: 머리 참조를 잠글 수 없습니다.
현재, 내 프로젝트의 모든 파일은 추적되지 않은 '새' 파일로 열거되어 있습니다.
현재, 나는 모든 내용을 삭제하고 새로운 서명을 해서 이 문제를 해결할 수 있지만, 나의 편집기 플러그인 때문에, 나는 이렇게 해서는 안 된다.

토론 #1

네, 이 문제를 해결했습니다.내가: Gcommit을 할 때, 그것은 나의 것을 다시 썼다.git/refs/heads/master 파일에는 제출한 GUID가 아닌 내 제출 메시지가 들어 있습니다.이것은 모든 것을 완전히 파괴했다.나는 이미 최신 GUID로 이 파일의 내용을 바꾸었고, 현재 나의 리포는 정상적인 기능을 회복했다.
그러나 이것은 나로 하여금 지금 사용하고 있는 Gcommit에 대해 긴장하게 한다.

토론 #2

아이고, 불행하다.당신은 시종일관 이 점을 재현할 수 있습니까? 아니면 이것은 일회용입니까?
사용 가능

echo 'ref: refs/heads/master' > .git/HEAD

master를 현재 지점으로 교체합니다.분명히 일이 이 지경까지 발전해서는 안 된다.

토론 #셋

네, 다시 프로그래밍하는 절차를 생각해 봤어요.
저장소에서 파일을 열고 변경한 다음 저장합니다.
:Gcommit
(방주, 나는vim을 나의 Git 편집기로 설정했다)
이거.git/index 파일이 파일 위에 있는 RO 창에서 열립니다.
"O"를 누르면 내가 있는 위치 위에 줄을 추가합니다. 이것은 정상적인 작업 절차입니다. (마찬가지로vim은Git 편집기이기 때문에 이것은 근육 기억입니다)
열어보겠습니다.git/refs/heads/master(현재 제출된 GUID 포함)
Git가 이 파일의 내용을 사용해서 변경 집합을 정하기 때문에 이 파일의 편집은 리포를 파괴할 수 있습니다.
Stack Overflow에 대해 연구를 한 후에 위에서 열거한 명령을 시도했지만 이 문제를 해결하지 못했다.'주'문건의 내용을 깊이 연구하고 찾아내 문제점을 제시했다.
Gcommit의 예상 동작은 무엇입니까?그것은 반침투 창을 열어야 합니까?아니면 Gcommit 행 (: Gcommit-m blahblahblah blah blah) 에서 제 소식을 제공해야 합니까?

토론 #4

야.:Gcommit에 인자가 없으면 :Gstatus를 호출합니다.이것은 당신git commit이 같은 상황에서 명령줄을 사용할 때 발생한 상황과 유사합니다.O 현재 줄의 파일로 이동합니다. 이 예는 refs/heads/master입니다.불행히도 근육의 기억은 이렇게 긴밀하게 배열되어 있다.생각해볼게요.refs/heads/master가 파괴되었기 때문에 이 파일을 복원해야 합니다.git reflog의 첫 줄을 보고 git show 연산을 해서 40개의 문자를 얻을 수 있습니다. 그 안에 넣을 해시를 찾을 수 있습니다.

토론 #5

네, 거의 다 고쳤어요.피드백해줘서 고마워요.
: Gcommit, 나는 나중에 이 점을 기억할 것이다.그렇지 않으면 나는 좋아한다
플러그 인.
감사합니다,
탕 버크스
수석 기술관
복모호.일반 도메인 이름 형식
닉러?장사
778 235 4334
2012년 3월 21일 수요일 오후 1:22, 팀 보프<
[email protected]
이 일도 나에게 일어났다.
1. 파일 편집
2.

토론 #6

3. 제출 메시지를 추가하고 :Gcommit<CR>(bash withoutO에서 git commit를 누르면 제출 메시지를 열 수 있습니다-m 내 예에서vim)
4.ref가 포함된 새로운 버퍼를 왜 열었는지 알고 싶습니다.이게 하나인 것 같아요.
기본 제출 메시지는 도주범이 추가하고, 줄에 쓰기
메시지를 제출하다.
5. $EDITOR6. 도주범이 내 머리를 잡아먹었다!:wq<CR>가 손상되었지만 복구할 정확한 참조를 찾기 위해 refs/heads/master를 실행할 수 없습니다.그러나 나는 git reflog에서 정확한 참고 번호를 찾았다.

$ tail -n4 .git/logs/HEAD

32547a3f786c8c766bde6d926dcecc3bf160f992 09a3648bfa2c74507b497dff86719876817daacf               username <email> 1395944116 -0400   commit: older commit message
32547a3f786c8c766bde6d926dcecc3bf160f992 d70def2d2f5875c0122bb952ef8e7f28316ecde7               username <email> 1395945403 -0400   commit: old commit message
32547a3f786c8c766bde6d926dcecc3bf160f992 0a77f1ae2c0a970112f24630f9bf19cd8a1d81da <-- THIS ONE! username <email> 1395945471 -0400   pull: Fast-forward

타임 스탬프를 검증함으로써, 나는 그것이 정확한 인용인지 다시 한 번 검사했다.이것은 unix epoch 형식입니다. 그래서 "1395945471 epoch in est"를 검색해서est로 변환했습니다.
네가 말한 대로 @tpope, 근육기억은 이곳의 킬러다.내 손가락은 매우 매우 클릭logs/HEAD하고 메시지를 제출하고 싶어 한다.나는 여전히 어떻게 O 제출 메시지를 정확하게 추가하는지 모른다.
그럼에도 불구하고 그는 여전히 도망자를 사랑한다.Gcommit 좋은 점은 극객 공포 영화의 좋은 제목을 얻을 수 있다는 것이다.
2014년 3월 27일 목요일 오후 3:18,[email protected]쓰기:
윌 도주범도 내 머리를 먹었다.
도망자 사랑해요.

토론 #7

이 일은 방금 나에게 발생했다.무서운 물건.
나는

토론 #8

없이 먼저 명중

토론 #9

을 쳤기 때문에 @tpope에서 언급한 바와 같이 :Gcommit에 들어갔다.내 생각엔 a:Gwrite를 클릭하여 필요한 변경 사항을 하고 버퍼 맨 위로 돌아가서 :Gstatus를 누르면 새 줄 ->Bam을 추가합니다.@mwcz note 때문에 이 문제가 해결되었습니다.- 그래, 한 가지 사실을 무시하자. O는 보통 메시지를 편집하기 시작하는 방식도 아니고, 보내는

토론 #10

의 같은 버퍼에서 편집하는 방식도 아니다.뇌에 방귀가 생겼다. 나는 뇌가 너를 현재의 지점으로 데려가는 것이 이상적이지 않다는 것을 안다.그리고요?완전히 다른 파일에 완전히 다른 옵션 카드에 위치하고 있는 것을 발견하면 일반적인 상태 설명이 없고 의외의 SHA만 포함되어 있으며 예상대로 삽입 모드에 있지 않을 때 머릿속에 무슨 생각을 하고 있습니까?당신은 어떻게'내가 모르는 이 줄을 삭제하고 두 번째로 삽입 모드에 들어가서 제출한 메시지를 쓰고 파일을 저장해야 합니까?'
나는 이 일을 얕보고 싶지 않다. 왜냐하면 그것은 분명히 여러 사람을 걸려 넘어뜨렸기 때문이다.그러나 '사용자 오류' 영역에 깊이 들어가는 문제에 대해 나는 일반적인 조작에 부정적인 영향을 미치지 않는 해결 방안만 받아들이고 싶다.따라서 첫 줄에서 삭제 O (가치가 제한되어 있어도), 읽기 전용 - 으로 설정하지 마십시오. (이것은 정말 우리가 해야 할 일이 아닙니다.)O 맨 앞에 빈 줄을 추가합니다.git/인덱스?HEAD "우습게 보인다"는 것은 나의 결점 리스트에서 매우 중요하다.

토론 #11

나는 이것이 사용자 오류 부서에 속하고 해결 방안을 찾기가 매우 쉽다는 것에 동의한다.가능한 해결 방안이 있는지 확실하지 않다.도움말 파일/readme/faq에 주석을 추가하기만 하면 됩니까?

토론 #12

변경

토론 #13

은 불가능하다는 것을 알지만, @tpope의 플러그인은 기본vim 명령을 직관적으로 덮어쓰는 데 뛰어나기 때문에 정말 이상하다고 말하고 싶습니다.이 예에서 Survious는 사용자에게 완전한 표준 텍스트 버퍼

토론 #14

를 제공했지만 O를 실행할 때 보았던 것과 완전히 같다) 첫 번째 합리적인 조작은 git commit였지만 O에 대한 응답은 매우 직관적이지 않았다.O 그래서 이게 왜 내가 내 환매를 계속 씻고 있는 거야!?!?!이 때문에 나는 줄곧 귀여운 vim 도주범을 사용하고 있다.그러면 작업 흐름은 Gwrite가 추가를 터치하고 그 다음은 Gcommit?

토론 #15

명령줄에서 사용하는 것과 똑같습니다.유일하게 곤혹스러운 것은 실패와 성공이 비슷해 보인다는 것이다. 왜냐하면 상태 출력이 두드러지기 때문이다.

토론 #16

@t는 내가 방금 다시 이 과정을 겪었으면 좋겠어. 네가 완전히 옳았으면 좋겠어.이런 상황이 1년여 전의 나에게 발생하였는데, 나의 기억은 내가 상상한 것처럼 그렇게 뚜렷하지 않다. 이것에 대해 나는 매우 미안하다.이것은 절대로 문법이 뛰어나서 나를 놀라게 했다.

토론 #17

: Gcommit(단계적 변경 또는 -a)

그것들은 내가 실제로 상태를 볼 때 제출 메시지를 편집하는 줄 알았을 정도로 비슷해 보였다.나는 git commit과/또는 읽기 공부를 해야 한다.:):syn off 네.나에게 이런 일은 자주 발생한다.내 손가락이 내 앞에 있어서 제출 메시지를 입력하기 시작하려고 해서 그들이 클릭한 것이 분명하다

토론 #18

.
복구는 문제가 되지 않습니다. Gstatus를 닫고 다시 열 수 있기 때문에 먼저 할 수 있습니다. O나는 버퍼링 구역을 수정한 적이 없지만, 내가 틀림없이 위험을 무릅쓰고 있다는 것을 알게 되어 기쁘다.
마음을 가라앉히고 논하다.
-ref 버퍼는 읽기만 하는 것 같은데?
- cc 메시지를 편집하기 위한 일반적인 방법은 아닐 수 있지만 다른 사람들은 그렇지 않을 수 있습니다.
- O/is/a 이상한 조합(일반적으로 줄 전체를 변경하는 데 사용...)cc 나는'먼저 해

토론 #19

'를 모르겠다.사실상, 당신이 이 곤경에서 시작한다는 것은 당신이 어떤 무대도 공연하지 않았다는 것을 의미한다. 이것은 cc 조작할 수 없는 cc 이 아예 없다는 것을 의미한다.Gstatus 를 실행하고 컨텐츠를 추가할 때 커밋을 시작하려면

토론 #20

를 실행해야 합니다.때때로 나는 버퍼가 제출 버퍼와 매우 비슷하기 때문에 잊어버리고 cc를 누르면 제출 버퍼를 편집하기 시작한다.
별거 아니야.하루에 적어도 한 번은 발생한다.약 2년 됐어요.나는 여전히 도주범을 좋아한다.
나는 지금까지 이 일을 생각해 본 적이 없지만, 이 댓글을 읽었으니, 나는 내가 반드시 제기해야 한다고 생각한다.
나는 지금까지 곤경에 빠진 적이 없고, 나도 원망한 적이 없다.나는 단지 발생할 수 있는 일을 설명하고 있을 뿐이다. 왜냐하면 나는 네가 모르는 일을 설명하기 위해 여러 가지 정보를 썼다고 생각했기 때문이다.만약 네가 이렇게 한다면 나를 거들떠보지 마라!
아마도 나는 모두에게 나의 작업 절차는 항상 Gstatus 창에서 시작된다고 말해야 할 것이다.나는 Gcommit을 사용하지 않는다. (왜냐하면 병렬 차이에서 간단한 심사를 허용하지 않는 것 같기 때문이다. 나는 이렇게 하는 것을 좋아한다.)O아, 나 드디어 망했어.나는 이번에 내가 리프 파일을 다시 쓸 때 도대체 무엇을 했는지 모르겠다.@mwcz에서 가장 가까운 머리 참고 자료를 안전하게 얻기 위한 절차에 감사드립니다.
이걸 복구하는 것은 나로 하여금 많은 스트레스를 절약하게 했다.