Вопрос по git, git-rebase – GIT Rebase Fatal для нескольких двоичных файлов емкостью 0,5 ГБ

12

[Этот вопрос по сути вновь открываетсяgit crash при перебазировании который никогда не имел ответа]

Я пытаюсь сделать ребаз с моего сайта secc. филиал как:

<code>$ git rebase main
First, rewinding head to replay your work on top of it...
fatal: Out of memory, malloc failed (tried to allocate 553656577 bytes)         # about 0.5 GB
$ git rebase --abort
No rebase in progress?
</code>

Ошибка связана с тем, что обе ветви и их общий предок имеют три файла .dat, каждый из которых имеет размер 0,5 ГБ.

Как я могу сделать ребаз в этой ситуации?

Дополнительная информация:

A 'git merge main' works just fine. Augmenting .gitattributes with '*.dat merge=keepTheirs' did not prevent the fatal. The *.dat files do differ. I'm willing to remove the *.dat files to rebase the others and then add back the *.dat. But how? I'm using git 1.7.9.4
Я просто просматривал некоторые из элементов git, начиная с 1.7.10, и произошли некоторые изменения, чтобы уменьшить использование памяти для очень больших файлов. Так что, может быть, вам повезет с самой последней версией. torek
Вы должны заглянуть в приложение git. Приложение Git является расширением Git для работы с большими файлами. Он хранит только контрольные данные в репозитории git и хранит большие файлы вне себя. bjhend
Можете ли вы создать патч для текущей ветки, воссоздать ветку, из которой вы пытаетесь выполнить ребазинг, и применить патч? vcsjones
«На практике я решил проблему, перейдя на более крупную (32 ГБ) машину». - проблема в том, что на компьютере недостаточно памяти, верно? eis
AFAIK (мне никогда не нужно было добавлять бинарные файлы в репо),git rebase вычисляет различия для изменений в одной ветви и повторно применяет их к другой фиксации (другая ветка "head"). Кажется, мерзавец выручил при разложении таких больших двоичных файлов. Если бы я был тобой, я бы переместил двоичные файлы вgit submodule и держите простую историю без перебазирования. Взгляни наstackoverflow.com/questions/540535/… KurzedMetal

Ваш Ответ

3   ответа
1

что выполнение этой же задачи с компьютером, который содержит больше, в данном случае 32 ГБ, памяти, решило проблему. Исходя из этого, я бы пришел к выводу, что у вас просто недостаточно памяти для того, чтобы сделать это на машине, с которой вы впервые попробовали.

Когда программа аварийно завершает работу и оставляет ваш рабочий каталог в аварийном состоянии (но подлежит восстановлению), после чего вы можете сказать: «О, мне нужна машина большего размера». - Ну, это не решение. GoZoner
... если, конечно, это не исправлено в последней версии Git. Однако, даже если это изменится изящно, у вас все равно будет слишком мало памяти для этого.
Кажется, проблема в том, что а) слишком мало доступной памяти и б) ненадлежащее обращение с ней. а) мы можем что-то сделать, б) это то, о чем следует сообщать разработчикам Git
Слишком мало памяти, чтобы сделать то, что конкретно - разве это не перебазирование, просто прививка одной ревизии к другой? Я предполагаю, что ему нужно вычислить новый хеш, но это об этом - git не загружает весь WC в память, чтобы вычислить хэш, не так ли? Сколько памяти на самом деле нужно git как кратному размеру WC - действительно ли у него слишком мало памяти или git нужно неоправданное количество, чтобы сделать что-то простое?
В чем разница с точки зрения пользователя? Требуется больше памяти, чем доступно на компьютере.
0

Попробуйте положить их в.git/info/attributes:

# whatever gets them...
yourfile binary -delta merge=binary
*.yourext binary -delta merge=binary

это "вызовет конфликты слияния, если эти файлы изменятся, и вам придется выяснить, что с ними делать". проверьте gitattributes и перебазируйте документ для других стратегий слияния, я даже не собираюсь называть здесь опасные.

Я не уверен, что это фактическое слияние, пытающееся запустить весь процесс в ядре, но, похоже, стоит попробовать.

1

достаточно ли велика ваша машина до тех пор, пока не произойдет сбой в работе "git rebase". но к этому моменту ваш каталог находится в скрытом состоянии. Во время перебазирования была извлечена другая ветвь (основная), так что «secc» изменения могут быть применены к нему. Восстановите и продолжайте:

git checkout secc

После сбоя при перебазировании, как вы уже заметили, у вас есть два варианта:

If rebase is not required, go with 'git merge main' Get a bigger machine and retry 'git rebase main'

У вас нет практической возможности игнорировать файлы объемом 0,5 ГБ, выполнить перебазирование и затем вернуть эти гигафайлы обратно.

Похожие вопросы