Improve performance for git prompts (on PowerShell)

[brian6932]

Code of Conduct

• I agree to follow this project's Code of Conduct

What would you like to see changed/added?

posh-git's not really maintained, there has been an open PR to improve the git status performance for quite some time (dahlbyk/posh-git#924). It's currently extremely sluggish (yes even with "ignore_submodules":{"*":"none"}). Realistically to have consistent performance across all supported shells, it would be nice for oh-my-posh to have it's own git status handling, either with git-status-cache or with it's own cache. Since that's a bit more involved, a quick solution for now would be to use https://github.com/zhengweidi/git-status-cache-posh-client/tree/master with https://github.com/zhengweidi/git-status-cache/tree/master, or something like gitstatusd https://github.com/romkatv/gitstatus.

[ivan-the-terrible]

Currently doing some reading about this. I like the note that's here on romkatv gitstatus README's Why Fast. This does make a lot of sense and I might seek to replicate the scenario used in the benchmarks.

I also understand the idea behind the PRs you listed from posh-git PR 924 using Get-GitConciseStatusFromCache (which is defined here).

There is a oh-my-posh does have a cache declared within the JSON file at AppData\Local\oh-my-posh\omp.cache.

Here is the setGitStatus function where the cache might be implemented:

Will dig further into the codebase to see what can be done and maybe put out a PR.

[ivan-the-terrible]

@brian6932 what would be really cool is if there is a Go package available with the logic :)
If you could poke around to find one, that would be extremely helpful.

[brian6932]

There's https://github.com/go-git/go-git I guess, you'd have to implement the caching on top of it, or just use the code from https://github.com/go-git/go-git/blob/master/status.go and work from there, as it'd reduce dependencies.

[JanDeDobbeleer]

Go git is terribly slow, tried it before. I don't mind adding support for existing cache tools, I'm not in favor of adding logic that aims to do what git itself should improve (faster status).

[brian6932]

I found starship (which uses gitoxide) to have a relatively performant git status prompt (https://github.com/mcwarman/starship/tree/feature/detailed-github-status), only thing's that submodules have to be disabled ([git_status] ignore_submodules = true), or else it becomes extremely slow, so it's definitely not impossible to parse git status from .git quicker.

[JanDeDobbeleer]

@brian6932 check, but as a maintainer, I need to be careful how far this can get pushed. And that's an implementation where I want to be in the lead so I can also keep offering support. It's not easy or straightforward or git would've fixed it already.

[elbkind]

Any updates on this? zsh had similiar problems and got it solved some time ago

[JanDeDobbeleer]

@elbkind this isn't shell related, it's git that's slow. I'm assuming you refer to powerlevel10k which implies the maintainer there created his own git status parser. This isn't straightforward and basically a path towards hell if you start messing with internals too much. I'm adding segment level caching that will for sure help with this, as you might not care for status every time, but in the end, it's git that's slow.

[jonathanjsimon]

@JanDeDobbeleer powerlevel10k's approach is indeed to offload the actual git interrogation to a another program called gitstatus that he wrote. It does take a caching approach as well.

https://github.com/romkatv/gitstatus

[JanDeDobbeleer]

@jonathanjsimon there are two elements here we can play with. Make your own git status parser, or identify when the folder contents changed. The first option is off the table for me, unless if I happen to make a living off of this. The second option could be feasible, depending on how fast we can determine that. Maybe there's another option I don't see yet though.

[jonathanjsimon]

@JanDeDobbeleer gitstatus is GLP 3.0. Could just use that, although I imagine it won't work on what I imagine is your primary target, Windows.

[JanDeDobbeleer]

@jonathanjsimon I respect his work, but as PL10K was also put on "hold", I'm not inclined to include work that's still dark magic for the most part and probably will only get best effort support as well. Not a strong foundation.

[jonathanjsimon]

@JanDeDobbeleer totally fair.