gitlockfile

Git: do not create index.lock for read-only operations

Is there a way to force git not to create index.lock for read-only operations like git status?

I'm displaying the status of my working tree in tmux, being updated every couple of seconds. Basically I parse the output of git status --branch --ignored --porcelain and a few other commands. Problem is, that for large repositories git status can take a few seconds to complete. During that time I cannot run any other git commands because the repository is locked.

EDIT:

Here are some pictures of the relevant part of my tmux line. Description for symbols from left to right:

In sync with remote branch | 2 staged changes | 1 unstaged change | 5 ignored files | 1 stash entry: enter image description here

In sync with remote branch | no changes in working tree | 5 ignored files: enter image description here

Ahead remote branch by 1 commit | no changes in working tree | 5 ignored files: enter image description here

Solution

  • What is about using "GIT_INDEX_FILE" environment variable to make the git to use another index file?

    So, to create a new index file from HEAD use

    GIT_INDEX_FILE=.git/other-index git reset

    and after it you could just 

    GIT_INDEX_FILE=.git/other-index git status

    to lookup for changes.

    The downside of it, you will not see the real status if the main index will be modified by add/rm commands. But at least it will allow you to detect the fact of a change and then probably do some more stuff to find out the real difference.

    Could you also describe more of the goal you are trying to achieve? Probably we could come out with some other solutions.

    Another idea. Try this:

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

    Not sure how reliable this... in case if cp command will happen while you are doing git add/rm, you could have "damaged" index file, and apparently get a failure, but for your use I believe it is good enough - you could just ignore the failure and retry.