Git: no cree index.lock para operaciones de solo lectura

¿Hay alguna manera de forzar a git a no crear index.lock para operaciones de solo lectura como el git status ?

Estoy mostrando el estado de mi tree de trabajo en tmux, que se actualiza cada dos segundos. Básicamente analizo el resultado del git status --branch --ignonetworking --porcelain de git status --branch --ignonetworking --porcelain y algunos otros commands. El problema es que para los repositorys grandes, el git status puede tardar unos segundos en completarse. Durante ese time no puedo ejecutar ningún otro command de git porque el repository está bloqueado.

EDITAR:

Aquí hay algunas imágenes de la parte relevante de mi línea tmux. Descripción para símbolos de izquierda a derecha:

En sincronía con la sucursal remota | 2 cambios por etapas | 1 cambio sin registrar | 5 files ignorados | 1 input oculta enter image description here

En sincronía con la sucursal remota | sin cambios en el tree de trabajo | 5 files ignorados: enter image description here

Por delante de la bifurcación remota por 1 commit | sin cambios en el tree de trabajo | 5 files ignorados: enter image description here

¿Qué pasa con el uso de la variable de entorno "GIT_INDEX_FILE" para hacer que el git use otro file de índice?

Por lo tanto, para crear un nuevo file de índice desde HEAD use

 GIT_INDEX_FILE=.git/other-index git reset 

y después de eso podrías simplemente

 GIT_INDEX_FILE=.git/other-index git status 

para search cambios

La desventaja de esto, no verá el estado real si el índice principal será modificado por los commands add / rm. Pero al less le permitirá detectar el hecho de un cambio y luego probablemente haga algunas cosas más para descubrir la diferencia real.

¿Podría describir más acerca del objective que está tratando de lograr? Probablemente podríamos presentar otras soluciones.

Otra idea. Prueba esto:

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

No estoy seguro de qué tan confiable es esto … en caso de que si el command cp ocurriera mientras está haciendo git add/rm , podría tener el file de índice "dañado", y aparentemente get un error, pero para su uso creo que es lo suficientemente bueno – puedes ignorar el error y volver a intentarlo.

Rápido y sucio, pero con la mayor security, simplemente podría usar un usuario con permissions de solo lectura.

 sudo -u nobody git status