git: Могу ли я всегда безопасно пытаться удалить index.lock?

Question

Я нашел несколько похожих вопросов, но не этот точный.Для справки, вот некоторые похожие проблемы:

, если git index.lock существует, могу ли я безопасно удалить его, или необходимы дополнительные действия для проверки целостности?

Git - фатально: невозможно создать '/path/my_project/.git/index.lock': файл существует

Я программно использую git для нескольких репозиториев и (Windows)приложение находится в цикле, выполняя «git pull», «git commit» и «git push», синхронизируя количество репозиториев с локальными и удаленными изменениями данных.

Иногда мое приложение сталкивается с «index.lock файл существует "проблема.Приложение используется в различных средах, где компьютер действительно может быть просто случайно выключен ... длинная история.

Вопрос: могу ли я просто написать код для попытки удаления index.lock каждый раз, когда приложение сталкивается с этой ошибкой?Это "безопасно"?

Я обеспокоен вопросами времени.Например, удерживает ли git этот файл открытым, пока он используется (поэтому моя попытка удаления будет неудачной), или удастся удалить не потерянный файл index.lock, а затем испортить мое хранилище?Или удаление index.lock из-под обновления индекса просто приведет к сбою этого обновления, и его нужно будет повторить в следующий раз, когда приложение выполнит цикл извлечения?

В других ответах говорится что-то вроде «убедитесь, чтоникакие git-процессы не выполняются перед удалением index.lock ", но это на самом деле не работает в реальном мире, потому что оно создает проблемы с синхронизацией - т.е. приложение просматривает, и нет никаких" git-процессов ", но до того, как оно удаляет index.lock aПроцесс git начинается.

Любое понимание - или нестандартные предложения - будет высоко ценится.Спасибо!

Answer 1

Нет, вы не можете.Файл блокировки существует по какой-то причине, и эта причина заключается в том, чтобы другие процессы не пытались выполнить запись в индекс, когда он используется.Способ работы файлов блокировки Git заключается в том, что Git создает файл блокировки, записывает новые данные в файл блокировки, а затем атомарно переименовывает старый файл поверх нового.

Если вы удалите файл блокировки, другой процесспри попытке записи индекса это не удастся (так как rename(2) не удастся), и этот процесс может быть чем-то вроде git commit или другим видимым пользователем процессом.Если индекс записывается из-за git add или подобного, вы не позволите этому процессу завершить или уничтожить свои изменения, и элемент не будет добавлен.Кроме того, если вы работаете в Windows, может быть даже невозможно удалить используемый файл.

Если вам абсолютно необходимо программно выполнить запись в репозиторий и избежать этой проблемы без взаимодействия с пользователем, тогдавам нужно использовать libgit2 или одну из ее оболочек и написать отдельный индексный файл для вашего программного процесса.В идеале для этой цели вы также должны использовать пустой репозиторий, поскольку рабочее дерево, скорее всего, не имеет значения.Это единственный способ гарантировать, что эта проблема не возникнет.

Как примечание, вы, скорее всего, потеряете данные, если компьютер просто случайно отключится.Git может синхронизировать объектные файлы с core.fsyncObjectFiles, но он не синхронизирует другие данные, и вы все равно можете получить поврежденные ссылки или индексный файл, полный нулей.Ни Git, ни libgit2 не предназначены для обработки этого случая.