gitstatus

For this, I just added a section to my prompt (bash) showing the state of my dotfiles repo (using yadm). This made sense to me because I'd already done this for a git repo in my current dir. I originally rolled my own but eventually found https://github.com/romkatv/gitstatus which is much faster. So, along with background fetches/pushes, at any point I can tell what revision my dotfiles repo is on and whether it's clean, up to date, conflicted, etc. The time cost for my whole prompt is <20ms.

I've posted some details explaining why gitstatusd doesn't use inotify in https://github.com/romkatv/gitstatus/commit/050aaaa04b652e15.... The short version is that the default max_user_watches limit is much too low to be useful for gitstatusd and I cannot ask or expect users to change their system settings.

The job of gitstatusd is to put Git status in your shell prompt. See screenshot at the top of https://github.com/romkatv/gitstatus. This is an amazingly convenient tool. When you are working on chromium, on every command you type gitstatusd needs to list the contents of 25,000 directories. Low level optimizations like the ones described here are what makes gitstatusd 10 times faster than `git status`, which in turn makes prompt responsive when otherwise it would be sluggish.

Take a look at the example: https://github.com/romkatv/gitstatus#gitstatusd. Even though this example uses ZSH, it's just for exposition. It launches gitstatusd, writes a request to its stdin, reads the request from stdout and prints it. You can discern from it the format it uses for requests and responses. There is also a formal description of request/response format in `gitstatusd --help`, or in https://github.com/romkatv/gitstatus/blob/master/src/options....

I just discovered this and haven't tried it yet. The reason why this is so much faster seems to mostly be that it uses https://github.com/romkatv/gitstatus (by the same author) as a daemon to get git status info. The classical way of running a dozen git commands gets really slow in complicated circumstances. I think previously you had to either limit displayed git info or update the prompt contents asynchronously to get a reasonable latency in a Zsh prompt.