Skip to content
This repository has been archived by the owner on Apr 24, 2020. It is now read-only.

Add gitstatus segment #1185

Closed
dritter opened this issue Mar 10, 2019 · 5 comments
Closed

Add gitstatus segment #1185

dritter opened this issue Mar 10, 2019 · 5 comments
Projects

Comments

@dritter
Copy link
Member

dritter commented Mar 10, 2019

As discussed in #1170 , we should add a gitstatus segment. This is faster than VCS_INFO, and could be included in 0.7.0 or 0.8.0. Just wanted to open this Issue that we don't forget.
If anyone wants to implement this, I'd be happy.

Pro/Con List of include this in the vcs segment:
👍 Users don't have to worry about this
👍 No duplication of tests. Obviously tests have to be duplicated (or be very similar) if not included.
👎 gitstatus does not support all use-cases we have in the vcs segment (AFAIR; correct me if I'm wrong).
👎 The vcs segment code is quite lengthy already
👎 Cleaner readme: The gitstatus install instructions can be addressed cleanly
👎 Easier handling: If for some reason (like user forgot to install gitstatus), it would just not work, so the feedback loop is cleaner. Otherwise it would fallback to VCS_INFO, pretending to work

@dritter dritter added this to To do in v0.7.0 via automation Mar 10, 2019
@JAicewizard
Copy link

Looking at the code from gitstatus it's not that big, I think porting/recreating it in go wouldn't be a horrible idea considering the xcompilation process.
I have a lot of projects to work on atm and don't even use zhs (came here via a reddit thread).
Maybe it would also be a decent to have a fallback with pure zhs if the platform isn't supported by the binary.

@dritter
Copy link
Member Author

dritter commented Mar 10, 2019

@JAicewizard This Issue is about using gitstatus in a dedicated segment. Not for rewriting it in go. A pure ZSH fallback would be to use the vcs segment..

@romkatv
Copy link

romkatv commented Mar 11, 2019

Looking at the code from gitstatus it's not that big, I think porting/recreating it in go wouldn't be a horrible idea.

I'd be delighted if you tried it. gitstatus gives you status of a git repo faster than git status, which has been optimized by more than a few capable devs. gitstatus uses a patched libgit2 (the official C library for git) that scans index and workdir 4x faster than the original. You can read details in libgit2/libgit2#4230 (comment).

@romkatv
Copy link

romkatv commented Mar 11, 2019

As discussed in #1170 , we should add a gitstatus segment.

Let me know if you need my help. This intro into gitstatus is decent: https://www.reddit.com/r/zsh/comments/azuzcq/additional_4x_git_prompt_speedup_in_powerlevel10k/eiam0lc. There are pointers to more details if you need them.

The most useful resource is probably https://github.com/romkatv/powerlevel10k/blob/master/powerlevel9k.zsh-theme where gitstatus is used in the vcs segment. The segment uses gitstatus when possible and falls back to vcs_info when gitstatus fails for some reason (I didn't get any reports of this ever happening but it's better to be safe than sorry) or when the current directory isn't a git repo and the user requested svn or hg support. Also, if gitstatus fails to load (e.g., unsupported architecture for which I don't have a compiled binary), vcs prompt will use vcs_info.

This segment is also async in powerlevel10k but not like other async things people do in ZSH. It doesn't use zpty but communicates with gitstatusd (the native binary) directly. It also don't use async for small repos where gitstatusd serves results in a couple milliseconds (this is to avoid segment flickering), but when results don't come for some time (the default threshold is 50ms) it switches to async and remembers that the specific repo is slow. The next time prompt is requested in the same repo, there will be no 50ms delay and the prompt will go async right away. If gitstatus serves results fast, the repo will once again be marked as fast, and the next prompt will wait for gitstatus results for up to 50ms again.

I'm sure you can figure it out. There isn't much code. I highly recommend trying out https://github.com/romkatv/powerlevel10k to get a feel of the UX. I've spent a lot of time making it smooth and responsive.

@dritter
Copy link
Member Author

dritter commented Apr 1, 2019

I just merged #1229 in next. 🎉

@dritter dritter closed this as completed Apr 1, 2019
v0.7.0 automation moved this from To do to Done Apr 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
v0.7.0
  
Done
Development

No branches or pull requests

3 participants