Git зависає під час запису об'єктів


100

Я намагаюся git push -u origin masterІ це просто зависає

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

12.65Частина зміщується навколо. Коли я виходжу з процесу і запускаю його знову, він поновлюється на 99%, але ніколи не закінчується, як і раніше.

Це ніколи не вдається успішно. Це початковий коміт.


Куди ти хочеш штовхнути? Ви використовуєте SSH або інший протокол?
Paŭlo Ebermann

26
Чи встановив би http.postbufferдопомогу? stackoverflow.com/questions/6842687 / ...
VonC

3
Коментар VonC занадто легко пропустити. Це працює для мене.
Туан,

1
Неймовірно. Це зробило це для мене теж. І зараз 2018 рік. І це SSH, а не HTTP. І весь репо - як 15 Мб. А "віддалений" сервер - 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
omg, дякую за це! висмикував мені волосся, і це вирішило мої проблеми!
Бретт Томас

3
@HugoForte Збільшення буфера, здавалося, вирішило моє зависання написання файлів, але мій git push ніколи не завершився (завис після Writing objects: 100%) - раніше він висів на 25%, тому це явно допомогло. Однак я все ще отримував "дивну" поведінку. Я перезапустив свою систему, і це, здавалося, вирішило щось ... FYI ... якщо хтось все ще стикається з проблемами після збільшення свого буфера, перезапуск моєї системи допоміг у моїй ситуації (рішення старої школи, тим не менше, але свіжий перезапуск дійсно допоміг).
twknab

4
Хтось може пояснити, звідки ця цифра 524288000?
Райр,

6
@Ryre це 500 Мб
Уго Форте,

1
Бог благословить вас і Stackoverflow, я б без поразки програв,
decoder7283

35

Це відбувалося через величезний, неігнорований файл у каталозі репо. Ой.

РЕДАГУВАТИ

Перерва сталася тому, що завантаження файлу тривало довго. Файл не повинен був бути включений у push.

РЕДАГУВАТИ

Хоча це правда, що причиною цієї проблеми може бути величезний файл, якщо ви не можете проігнорувати файл, про який йде мова, або просто його потрібно натиснути, то слідуйте цій відповіді.


@TimoSolo Чому я повинен це робити? Я був одним із проблемою, і я задокументував точне виправлення. Досить просто.
mattalxndr

4
Так, виправлення полягало в тому, щоб усунути проблему. Задля інших людей, яким насправді потрібно натиснути великий файл, відповідь @ hugo-forte вирішує проблему. Вам не потрібно , я просто думав, що це допоможе більшій кількості людей - у дусі SO.
TimoSolo

1
Питання не в "Як я можу зафіксувати, а потім натиснути величезний файл?". Це "Мій git push нескінченний. Чому?" Якщо ви не очікуєте, що поштовх триватиме назавжди, то ви, мабуть (як і я), не мали на меті зафіксувати цей величезний файл.
mattalxndr

3
@mattalxndr Коли прийнята відповідь набере 1/8 голосів, ви, мабуть, повинні змінити її.
NorCalKnockOut

1
@mattalxndr Жодна відповідь не є ідеальною. Один визначає причину, а інший пропонує рішення. Ідеальна відповідь дозволить визначити причину, пояснити, чому вона дає даний результат, і запропонувати два альтернативні рішення. ІМО, з поточних варіантів, відповідь Уго Форте є вищою, оскільки вона вирішить проблему незалежно від того, чи хотіли ви натиснути файл чи ні. Це не ігнорування людей, які допустили ту ж помилку, що і ви; він вирішує проблему для них так само, як і будь-хто інший, але залишає за ними можливість видалити файл, якщо вони не мали наміру його натискати.
BZ1,

7

У мене була та ж проблема з (написанням об'єктів% 16), що застрягла, а потім призвела до смертельного результату. Я вирішив це, збереживши поточні зміни та клонуючи нове сховище, а потім скопіювавши в нього змінені файли.

Напр. Припустимо, що поточним сховищем є A, тоді все, що вам потрібно зробити, це:

  1. mv A B
  2. git clone A
  3. mv B/* A/
  4. rm -rf B

Потім фіксуйте і натискайте, і все працювало нормально. Він визнав переміщені файли зміненими :)


Ви відчували інший симптом. У моєї не було фатальних помилок.
mattalxndr

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.

Git зависає

Рішення

src > chmod -R 775 /tmp/dst

2
Будь ласка, розгляньте можливість додати ще кілька зразкових деталей до своєї відповіді, дякую.
Мірза Сісіч

1
Вибачте. Чи краще?
Naewis

3

У моїй ситуації це був розмір файлу. Додавши файл .gitignore із необхідними розширеннями, я зміг проігнорувати більшість небажаних файлів, які потрібно було висунути.


2

У моєму випадку у мене була повільна швидкість завантаження з Інтернету, і файл, який я хотів натиснути, був великим, фокус полягає у використанні git LFS (велике сховище файлів), яке набагато терпляче завантажує великі файли, ви можете знайти підручник з Git LFS тут


1

git clean -f -nвирішує моє питання. Багато файлів, що не відстежуються, не виявлено. Але будьте обережні, оскільки це призведе до видалення файлів з вашого каталогу


3
Зокрема, які файли він буде видалений?
Язимов

1

У моєму випадку я намагався натиснути, не виконуючи правил своєї компанії. Пізніше я дізнався, що ми повинні починати наші повідомлення про коміти з "MOBIL-XXXX", де XXXX - це кількість, яку розробники призначають в Jira (інший інструмент, який ми використовуємо для відстеження процесу розробки) аналістами.

Обов’язково перевірте, чи є у вашої компанії подібне правило обмеження.


0

У мене була та сама проблема на машині Windows 10, writing objectsвона зависала, але в трохи іншій ситуації.

Проблема у мене була лише тоді, коли я намагався додати нові файли до сховища. Якщо я оновлюю файли, які вже існують у сховищі, все працює нормально, і насправді не має значення, великий розмір файлу чи ні. В основному я намагався додати нові сценарії.

Я спробував усі інші рішення, знайдені в Інтернеті, але в моєму випадку нічого не працювало, і останнє, що я спробував, насправді спрацювало. Здається, це було через деякі дозволи Windows для певного диска та папки, що заважає програмі писати в цих конкретних папках або оновлювати файли, навіть коли я ввійшов в систему з обліковим записом адміністратора та запускав програму як адміністратор. Отже, ця команда:

attrib -r +s D:\foldername 

вирішив проблему для мене.

Просто розмістивши його тут, можливо, хтось має таку ж проблему, як моя.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.