개체를 쓰는 동안 힘내가 멈춤

100

나는 노력하고 git push -u origin master있고 그것은 단지 매달려

Writing objects:  99% (219/220), 12.65 MiB | 97 KiB/s

12.65부분은 주위를 이동합니다. 프로세스를 종료하고 다시 실행하면 이전과 같이 99 %에서 다시 시작되지만 완료되지 않습니다.

성공적으로 푸시되지 않았습니다. 이것은 초기 커밋입니다.

git

— Mattalxndr
소스

어디로 밀고 싶습니까? SSH 또는 다른 프로토콜을 사용하고 있습니까?

— Paŭlo Ebermann

26

http.postbuffer도움을 주겠습니까 ? stackoverflow.com/questions/6842687/...

— VonC

3

VonC의 의견은 간과하기 너무 쉽습니다. 그것은 나를 위해 작동합니다.

— Thuan

1

믿을 수 없는. 그것은 나에게도 해주었다. 그리고 지금은 2018 년입니다. 그리고 HTTP가 아닌 SSH입니다. 그리고 전체 저장소는 15MB와 같습니다. 그리고 "원격"서버는 localhost입니다. Git, 여러분, 제발 로맨틱 화하지 마세요! ;)

— Sz.

219

VonC의 조언을 따랐습니다.

git config --global http.postBuffer 524288000

향후 참조를 위해 의견을 기반으로 :

500 MB: 524288000 (as posted in the original answer)
1 GB: 1048576000
2 GB: 2097152000 (anything higher is rejected as 'out of range')

— 휴고 포르테
소스

4

세상에, 감사합니다! 내 머리카락을 뽑아 내고 있었는데 이것이 내 문제를 해결했습니다!

— Brett Thomas

3

@HugoForte 버퍼를 늘리면 내 파일 쓰기가 해결되는 것처럼 보였지만 내 자식 푸시는 완료되지 않았습니다 (후에 중단됨 Writing objects: 100%). 이전에는 25 %에서 중단되었으므로 분명히 도움이되었습니다. 그러나 나는 여전히 "이상한"행동을하고 있었다. 나는 내 시스템을 다시 시작 했고 이것이 문제를 해결하는 것처럼 보였습니다 ... 참고로 ... 누구나 버퍼를 늘린 후에도 여전히 문제가 발생하면 내 시스템을 다시 시작하는 것이 내 상황에 도움이되었습니다 (오래된 학교 솔루션은 그다지 좋지 않았지만 새로 다시 시작하는 것이 실제로 도움이되었습니다).

— twknab

4

누구든지 번호의 524288000출처를 설명 할 수 있습니까 ?

— Ryre 2017 년

6

@Ryre 500MB

— Hugo Forte 17 년

1

신의 축복과 Stackoverflow, 나는 완전한 패배자가 될 것입니다.

— 디코더 7283

35

이것은 repo 디렉토리에있는 무시되지 않는 거대한 파일 때문에 발생했습니다. 이런.

편집하다

파일을 업로드하는 데 시간이 오래 걸리기 때문에 중단되었습니다. 파일이 푸시에 포함되어서는 안됩니다.

편집하다

대용량 파일이이 문제의 원인이 될 수 있다는 것은 사실이지만 문제의 파일을 무시할 수 없거나 푸시 해야하는 경우이 답변 을 따르십시오 .

— Mattalxndr
소스

@TimoSolo 내가 왜 그럴까요? 나는 문제가있는 사람이었고 정확한 수정 사항을 문서화했습니다. 꽤 직설적 인.

— mattalxndr

4

예, 해결 방법은 문제를 제거하는 것입니다. 실제로 큰 파일을 푸시해야하는 다른 사람들을 위해 @ hugo-forte의 답변이 문제를 해결합니다. 당신은 그럴 필요 가 없습니다 . 나는 그것이 SO의 정신으로 더 많은 사람들을 도울 것이라고 생각했습니다.

— TimoSolo

1

질문은 "어떻게 커밋 한 다음 대용량 파일을 푸시 할 수 있습니까?"가 아닙니다. "내 자식 푸시는 끝이 없다. 왜?" 푸시가 영원히 걸릴 것이라고 기대하지 않는다면, 아마도 (나처럼) 그 거대한 파일을 커밋 할 생각은 없었을 것입니다.

— mattalxndr

3

@mattalxndr 수락 된 답변의 표가 1/8이면 변경해야합니다.

— NorCalKnockOut

1

@mattalxndr 둘 다 완벽하지 않습니다. 하나는 원인을 식별하고 다른 하나는 솔루션을 제공합니다. 이상적인 대답은 원인을 식별하고, 주어진 결과가있는 이유를 설명하고, 두 가지 대체 솔루션을 제공하는 것입니다. IMO, 현재 옵션 중에서 Hugo Forte의 대답은 파일을 푸시할지 여부에 관계없이 문제를 해결하기 때문에 우수합니다. 당신이했던 것과 같은 실수를 저지른 사람들을 무시하는 것이 아닙니다. 다른 사람과 마찬가지로 문제를 해결하지만 파일을 푸시 할 의도가없는 경우 파일을 제거하도록 남겨 둡니다.

— BZ1

7

(개체 % 16 쓰기)와 같은 문제가 발생하여 치명적이었습니다. 현재 변경 사항을 저장하고 새 저장소를 복제 한 다음 수정 된 파일을 여기에 복사하여이 문제를 해결했습니다.

예 : 현재 저장소가 A라고 가정하면 다음과 같이하면됩니다.

mv A B
git clone A
mv B/* A/
rm -rf B

그런 다음 커밋하고 푸시하면 모두 잘 작동했습니다. 이동 된 파일이 수정 된 것으로 인식했습니다. :)

— 마하
소스

다른 증상을 경험했습니다. 내 것은 치명적인 오류가 없었습니다.

— mattalxndr 2013

5

제 경우에는 저장소와 동일한 드라이브에 저장된 잘못된 권한이있는 git 폴더를 사용하고 있었지만 인증 된 로그인 사용자를 사용하더라도 ssh와 동일 할 수 있습니다.

그런 다음 먼 저장소에 쓸 올바른 권한이 있는지 확인하십시오.

예:

로컬 및 원격 저장소 초기화

git init /tmp/src
git init --bare /tmp/dst
cd /tmp/src

오리진에 원격 저장소 추가

src > git remote add dest /tmp/dst

문제 시뮬레이션

src > chmod -R 555 /tmp/dst

가짜 파일 추가 및 푸시

src > touch a && git add a && git commit -m 'demo'
src > git push --set-upstream dest master
src > git push
Counting objects: 3, done.
Writing objects: 99% (2/3), 202 bytes | 0 bytes/s.

힘내 중단

해결책

src > chmod -R 775 /tmp/dst

— Naewis
소스

2

답변에 몇 가지 예시적인 세부 정보를 더 추가해보세요. 감사합니다.

— Mirza Sisic

1

죄송합니다. 더 낫습니까?

— Naewis

3

제 상황에서는 파일의 크기였습니다. 필요한 확장자를 가진 .gitignore 파일을 추가함으로써 푸시 할 원치 않는 파일 대부분을 무시할 수있었습니다.

— Skitty
소스

2

제 경우에는 인터넷 업로드 속도가 느리고 푸시하고 싶은 파일이 컸습니다. 트릭은 큰 파일을 업로드하는 데 훨씬 더 오래 참을성있는 git LFS (대용량 파일 저장소)를 사용하는 것입니다. 여기 에서 git LFS 자습서를 찾을 수 있습니다.

— user3160702
소스

1

git clean -f -n내 문제를 해결합니다. 감지되지 않은 추적되지 않은 파일이 많이 있습니다. 그러나 이렇게하면 디렉토리의 파일이 제거되므로주의하십시오.

— 셜록
소스

3

특히 어떤 파일을 제거합니까?

— Jazimov

1

제 경우에는 회사 규칙을 완성하지 않고 밀어 붙이려 고했습니다. 나중에 "MOBIL-XXXX"로 커밋 메시지를 시작해야한다는 것을 배웠습니다. 여기서 XXXX는 분석가가 Jira (개발 프로세스를 추적하는 데 사용하는 또 다른 도구)에서 개발자에게 할당 한 번호입니다.

회사에 유사한 제한 규칙이 있는지 확인하십시오.

— 오낫 코 루쿠
소스

0

Windows 10 컴퓨터에서 동일한 문제가 발생하여 writing objects중단되었지만 약간 다른 상황에 있습니다.

내가 가진 문제는 저장소에 새 파일을 추가하려고 할 때만 발생했습니다. 저장소에 이미 존재하는 파일을 업데이트하면 모든 것이 제대로 작동하고 파일 크기가 크든 아니든 상관 없습니다. 대부분 새 스크립트를 추가하려고했습니다.

나는 인터넷에서 찾은 다른 모든 솔루션을 시도했지만 내 경우에는 아무것도 작동하지 않았고 실제로 시도한 마지막 작업은 작동했습니다. 특정 드라이브 및 폴더에 대한 일부 Windows 권한 때문에 관리자 계정으로 로그인하고 관리자로 앱을 실행하더라도 앱이 특정 폴더에 쓰거나 파일을 업데이트하지 못하도록하는 것 같습니다. 따라서이 명령 :

attrib -r +s D:\foldername

나를 위해 문제를 해결했습니다.

여기에 게시하면 누군가 나와 같은 문제가있을 수 있습니다.

— h4rd4r7c0r3
소스