Необычно долго проталкивать репо

Я попытался переместить свое локальное репо на удаленный компьютер и заметил, что это занимает безбожное количество времени. Я немного поискал и наткнулся на git-sizer. При запуске git-sizer создается следующий отчет

Processing blobs: 1508                        
Processing trees: 315                        
Processing commits: 22                        
Matching commits to trees: 22                        
Processing annotated tags: 0                        
Processing references: 1                        
| Name                         | Value     | Level of concern               |
| ---------------------------- | --------- | ------------------------------ |
| Biggest objects              |           |                                |
| * Trees                      |           |                                |
|   * Maximum entries      [1] |  4.71 k   | ****                           |
| * Blobs                      |           |                                |
|   * Maximum size         [2] |   440 MiB | !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
|                              |           |                                |
| Biggest checkouts            |           |                                |
| * Maximum path length    [3] |   142 B   | *                              |
| * Total size of files    [4] |  8.55 GiB | *********                      |

[1]  c51165063bd15a74a3a9f5b03dd40c42f70e004e (7273dece03a5fd401b70c8bf04da67f5f6491d43:maxlife_10m_data.snappy.parquet)
[2]  8e1f3fa7aa5fd70ca4cabc8a3d0f4e20517f050c (1ba7cf0afc90c55b16cc15555ef17d54354c354b:tests/test_output_data/fep_tests/multi_clf_fe_output_train_data.csv/multi_clf_fe_output_train_data.csv)
[3]  17d038c0621352725bfc1e7d3bf38ed4480b69a1 (1ba7cf0afc90c55b16cc15555ef17d54354c354b^{tree})
[4]  a959c9e3fe72b7f0a14e1ed188c9130fabc7f526 (3cacec40355ddc12c0fd5d1ba9d1901da47e3843^{tree})

В разделе Biggest checkouts упоминается цифра около 8,5 ГБ, что определенно намного больше, чем размер моего репо ~ 100 КБ. Как мне решить эту проблему?

Похоже, в вашем репо есть большие файлы Blob. GIT не может отслеживать изменения в больших двоичных объектах и ​​будет добавлять новый каждый раз, когда они меняются. В основном не помещайте двоичные файлы в свое репо.

Liam 08.08.2018 12:27

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

Liam 08.08.2018 12:29

О, вы также захотите удалить этот файл из всех предыдущих проверок, чтобы он исчез. Поэтому вам нужно переписать коммиты, включающие этот файл. См. Как я могу полностью удалить файл из репозитория git?

Liam 08.08.2018 12:30

@Liam, Нет. У меня нет образа или резервной копии базы данных. Самый большой файл, который у меня есть, - это csv-файл размером 12 КБ. Кроме того, я не уверен, что это за двоичные файлы? Включает ли он файлы csv? Насколько я понимаю, это не так. Раньше у меня была куча больших CSV, но теперь, когда я отправляю их на удаленный доступ, я сделал для них git rm --cached <file>.

Clock Slave 08.08.2018 12:33

@Liam, я пробовал ссылку, которую вы добавили выше, но получается Cannot rewrite branches: You have unstaged changes.

Clock Slave 08.08.2018 12:35

git remove удаляет только последний файл. Файл по-прежнему будет существовать в истории. Эти CSV-файлы кажутся мне виноватыми. Похоже, ваша ошибка предполагает наличие неустановленных изменений. Перезапись репозитория - довольно сложная задача. Тот факт, что вас смутило это сообщение об ошибке, говорит о том, что вы не так уверены в использовании GIT, поэтому будьте осторожны.

Liam 08.08.2018 12:42

@ Лиам. Вы прямо здесь. Я очень плохо понимаю, как работает git. Есть идеи, в каком направлении мне следует двигаться?

Clock Slave 08.08.2018 12:46

Думаю, я помог здесь, чем мог. Это появляется, что эти файлы CSV выдаются вами. Быстрое решение - начать новое репо с нуля, но это, очевидно, будет означать, что вы потеряете всю свою историю.

Liam 08.08.2018 12:48

Хорошо, я проверю, можем ли мы позволить себе потерять историю по этому поводу. Спасибо, @Liam.

Clock Slave 08.08.2018 12:53

другой вариант - потратить некоторое время на попытки переписать историю. При условии, что вы делаете это с копией своего репо и не нажимаете до тех пор, пока не будете на 100% уверены, что можете ограничить любой ущерб, который можете нанести. Это все описано в связь. Удачи

Liam 08.08.2018 12:55
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
10
20
0

Другие вопросы по теме