Восстановление git после сбоя ПК

[Nick222]

Здравствуйте!

После подвисания компа и перезагрузки проверил диски (SSD) - всё вроде в норме.

Через неделю обнаружил, что автоматически работающий репозиторий git не обновляется и вообще при попытке просмотра через разные GUI он как бы пустой.

При проверке в репозитории git обнаружил четыре нулевых файла и их удалил (не знаю, можно ли это было делать).

Также есть один "missing blob". Но я побоялся его трогать.

В конце концов обнаружил, что директория .git/refs/heads/ стала пустой - и никакого master там нет.

У меня есть полная физическая копия прежнего состояния репозитория месячной давности.

Искал в Интернете, понял, что нужно как-то восстановить master.
Где и как найти эту SHA1 и к чему эта контрольная сумма относится?

Что-то я запутался - как восстановить всё, чтобы большая часть репозитория, включая изменения за последний месяц, восстановилась и он снова начал работать (сейчас он не обновляется)?

Спасибо

[F12]

Nick222, а проект твой?..

[Nick222]

Ну да. Репозиторий на локальном диске у меня.

[F12]

Репозиторий на локальном диске у меня.

- т.е. проект только твой, и он у тебя на локальном диске, а в облаке ничего нет?

[Skif_off]

При проверке в репозитории git обнаружил четыре нулевых файла и их удалил (не знаю, можно ли это было делать).

Есть же бэкап, можно было посмотреть состояние файлов... Пустые файлы в ".git" могут быть, но без имён не узнаем, могут ли конкретно эти быть пустыми.

Если в репозитории одна ветка и собственно файлы целы (в смысле всё остальное кроме ".git"), то почему бы не забить, одновив ими файлы из бэкапа?

[Nick222]

проект только твой, и он у тебя на локальном диске, а в облаке ничего нет?

Да
Пользователь добавил сообщение 30 Сентября 2025, 10:04:46:

Пустые файлы в ".git" могут быть, но без имён не узнаем, могут ли конкретно эти быть пустыми.

Ну он дал мне список ошибок - типы сбойные файлы.
Я их нашёл - у них нулевой размер - и стёр.
Пользователь добавил сообщение 30 Сентября 2025, 10:08:10:

Если в репозитории одна ветка и собственно файлы целы (в смысле всё остальное кроме ".git"), то почему бы не забить, одновив ими файлы из бэкапа?

На сегодня есть нормальная физическая копия репозитория месячной давности.
Есть сбойный репозиторий последний - перенесён в другое место и работа с ним остановлена.
И я начал заново с нуля, создав новый репозиторий.

Вопросы:

1) Как из того сохранённого в бэкапе нормального импортировать всё в новый? Получается, нужно менять начальную точку?

2) Можно ли из сбойного бэкапа как-то импортировать то не сбойное, что было за последний месяц и как?
Пользователь добавил сообщение 30 Сентября 2025, 10:11:37:Мне нужно как-то обезопасить себя от сбоя - подвисает комп.

Смысла особого делать клон на другом диске не вижу, т.к. подвисает вся дисковая подсистема тоже.

Или можно настроить так, чтобы при сбое основного репозитория его копия не изменялась бы сразу?
Пользователь добавил сообщение 30 Сентября 2025, 10:12:21:Удалённый репозиторий делать не могу и не хочу.
Только если у себя же на диске...
Пользователь добавил сообщение 30 Сентября 2025, 11:00:37:Отдельный вопрос - не знаю, сюда или нет:

Почему-то gitg (в отличие от других GUI для GIT) при попытке открыть репозиторий грузит процессор на 25-30% и отжирает оперативную память не по-детски...
Это нормально? что он там делать может? Или он устарел стоит пользоваться каким-то другим GUI для GIT ?
Компу 15 лет. Xubuntu 25.04.

[andytux]

Компу 15 лет. Xubuntu 25.04.

Тяжёлым тебя по лбу. Может так наступит просветление, "что грузит и отжирает".

[Nick222]

))

Я тут пробовал сделать экспорт только не потерянных коммитов из сбойного репа - получил 60 Гб файл - потёр всё на фиг.

Вопрос - нельзя ли как-то сохранять только последние 30 суток коммитов, а остальные удалять (например, объявляя начальным состояние возраста 30 суток)?
Или надо делать отдельную ветку каждые 30 суток - а куда девать более старые?

[Skif_off]

Вопрос - нельзя ли как-то сохранять только последние 30 суток коммитов, а остальные удалять (например, объявляя начальным состояние возраста 30 суток)?
Или надо делать отдельную ветку каждые 30 суток - а куда девать более старые?

Всё оно никуда не денется из истори коммитов от начального состояния.
Как вариант - с "git rebase" раз в 30 суток сливать пачку коммитов в один. Правда, при необходимости просмотреть изменения лучше быть не понаслышке знакомым со словлм "самадхи" )

Собственно, нам же ничего не известно ни о содержимом, ни о размере оного.

P.S.

Компу 15 лет.

Зачем люди подобное пишут? (Вообще.) Совершенно же непонятно - то ли там огрызок-Celeron, то ли топчик i7 на 1366м сокете... Ну или Thuban, которым FX'ы в однопотоке сливали неприлично.

[Nick222]

ОК

Тогда вопрос:
- сохранился в бэкапе реп от 01 сентября.
- есть совершенно новый рэп от 01 октября.

Как заставить git слить их в одну линию, учтя при этом обобщённую разницу между состояниями проекта от 01 сентября и от 01 октября?
Пользователь добавил сообщение 01 Октября 2025, 13:42:46:

gitg (в отличие от других GUI для GIT) при попытке открыть репозиторий грузит процессор на 25-30%

Мне кажется, что дело именно в алгоритме софта.
При попытке открыть начальное состояние проекта разница между GITK и GITG огромна, а при открытии остальных коммитов - незаметна.
Те, кто начинает свой проект практически с нуля, этого не замечают.
А я скормил GIT-у как начальное состояние 50 Мб текста на 13 тыс файлов и сотни папок.
Если бы это было разбито на мелкие коммиты за несколько лет, то вряд ли бы программа просмотра тормозила, ИМХО.