Git: не создавать index.lock для операций только для чтения

Есть ли способ заставить git не создавать index.lock для операций только для чтения, таких как git status?

Я показываю статус моего рабочего дерева в tmux, обновляюсь каждые пару секунд. В основном я анализирую вывод git status --branch --ignored --porcelain и несколько других команд. Проблема в том, что для больших репозиториев git status может потребоваться несколько секунд. За это время я не могу запускать какие-либо другие команды git, потому что репозиторий заблокирован.

EDIT:

Вот несколько снимков соответствующей части моей линии tmux. Описание символов слева направо:

Синхронизация с удаленной ветвью | 2 поэтапных изменения | 1 неустановленное изменение | 5 проигнорированных файлов | 1 запись:

Синхронизация с удаленной ветвью | никаких изменений в рабочем дереве | 5 игнорируемых файлов:

Впереди удаленная ветвь на 1 фиксация | никаких изменений в рабочем дереве | 5 игнорируемых файлов:

Ответ 1

Что связано с использованием переменной окружения "GIT_INDEX_FILE", чтобы сделать git использовать другой файл индекса?

Итак, для создания нового индексного файла из HEAD используйте

GIT_INDEX_FILE=.git/other-index git reset

и после него вы могли бы просто

GIT_INDEX_FILE=.git/other-index git status

для поиска изменений.

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

Не могли бы вы также описать больше цели, которую вы пытаетесь достичь? Вероятно, мы могли бы найти другие решения.

Другая идея. Попробуйте следующее:

cp .git/index .git/other-index # or maybe just "ln" once, rather than copying everytime?
GIT_INDEX_FILE=.git/other-index git status

Не уверен, насколько это достоверно... в случае, если команда cp будет выполняться во время выполнения git add/rm, у вас может быть "поврежденный" индексный файл и, по-видимому, получить сбой, но для вашего использования я считаю, достаточно хорошо - вы можете просто проигнорировать сбой и повторить попытку.

Ответ 2

Быстро и грязно, но наиболее безопасно вы можете просто использовать пользователя с разрешениями только для чтения.

sudo -u nobody git status