Add support for gitstatusd

[arkq]

When git repository is very big (lots of submodules and submodules of submodules) running git status is very slow. Recently I've discovered a project https://github.com/romkatv/gitstatus which claims to be 10x baster than git status. And in fact it is (tested by myself on ~20GB repo, with many many number of files and submodules).

Unfortunately the gitstatusd is not a simple replacement for git status. It can be run as a daemon process which can be used for querying git status of given repository, so direct integration in liquidpromp would be required.

Description

It would be nice to be able to switch from git status to gitstatusd if desired (or maybe automatically switch to gitstatusd if executable is available).

How will this be useful?

It will improved responsiveness of liquidprompt when browsing git repository (especially big ones).

Example prompt

The prompt should stay as it is right now.

[Rycieos]

This is for sure something we need to support. Likely we would want a config option for it (LP_ENABLE_GITSTATUSD), and autodetect if gitstatus_check() returns true, otherwise disable the feature. That would require the user to manage the sourcing of gitstatus.plugin.sh or gitstatus.plugin.zsh and running the gitstatus_start() function themselves.

The bigger trick will be the backend work inside liquidprompt to enable different ways to get the git data. Probably more work caching things.

[nojhan]

Is someone working on that?

[Rycieos]

No, no one is working on this to my knowledge. I took a shallow look at it before, and it seems doable, but a lot of work in liquidprompt internals to support multiple ways of fetching git data.

Honestly, this inspired me to think about other ways to speed up the prompt. Not to follow in @dolmen's shoes, but I have been toying around with the idea of a terminal prompt engine that runs as a daemon (like his angel-PS1). What kills most Liquid Prompt competitors is startup cost in loading the binary (which Liquid Prompt avoids because it runs native in the shell). Anyway, this is a tangent (that I would be happy to discuss with anyone interested).

All that to say that I have little interest in implementing this myself (at this time), as I would rather daemonize the whole prompt engine. So unless someone else picks this up, it will probably miss v2.2.