zshrc: making more information about your VCS status available in the prompt

[booboo-at-gluga-de]

…if CWD is under version control

You get

• a "!!" if you have modified files (not yet added)
• a "C" if you have added files, but not yet committed
• (for now git only) a "U" if you have untracked files
• (git only) a "S" plus a number indicating the stash length
  if you added something to you stashing area (git stash)
• (git only) a "P" plus a number indicating the number of pending commits
  if you have commits not yet pushed to upstream

I like having the info available always my working directory is unclean - so I improved my prompt. Would like to share it, because I think others (especially people dealing a lot with VCS) could consider this to be helpful too.

[ft]

The reason we didn't enable features like check-for-changes before is, that they are
expensive as hell and we didn't want to cause lagging prompts in large git repositories.

I glanced at the code and it didn't raise any immediate flags. However, I'm still weary
about enabling these for everyone, because the old reasons are still valid.

[mika]

I'd really like to see such a feature available in our grml-zshrc, could be even enabled by default as long as it's easy and obvious how to disable that. Is there any chance to either timeout or automatically disable it (and maybe even mention that within the prompt?) if loading takes longer than e.g. 3 seconds or so?

I'm using the following configuration within my personal .zshrc.local:

https://gist.github.com/mika/e30b4e99c338f5d80d7681407708609b

Maybe we can even combine our approaches in some way, what do you think,
@booboo-at-gluga-de + @ft?

[ft]

Timing out would be non-trivial and require changes to vcs_info.

Personally, I still think that we shouldn't enable too many features in this regard. I probably wouldn't even enable check-for-changes and leave that to the user to pick and choose.

Obviously, mika has the final say about this.

[booboo-at-gluga-de]

Hi @mika
Hi @ft

sorry for not replying for such a long time - lots of other important stuff to do.

Meanwhile created a version which does not need check-for-changes but provides the same information as the version before. I tested this version with big and complex git repos and did not experience any performance issues - according to my tests the prompt is always displayed immediately, in any case far less then 1 sec.

Please have a look at this as soon as you can find some time. What do you think about this one?

Greetings from Nürnberg,
Bernd

[mika]

Ping @ft - maybe you could review this once you've a few spare minutes? :)

[booboo-at-gluga-de]

Agree! That would be great!

[sometimesfood]

While the additional information is nice to have, the proposed changes seriously hurt performance on various Non-Linux platforms.

On my Linux machines I do not notice any serious lag, but on my 2017 Macbook Air (macOS 10.13, zsh 5.3), the proposed changes render the Grml zshrc almost unusable (+600ms for "cd ~/src/grml-etc-core", similar for repos with <50 commits and a small number of files). On my OpenBSD boxes, the increased latency is quite noticeable as well. (If I quickly hit return five or six times in a row, I can actually watch zsh slowly catch up afterwards. With the 2018.12 zshrc no such delay is noticeable.)

If you consider merging these changes, please add a simple way to disable them completely (export GRML_NO_EXTENDED_VCS_STATUS=1 or something similar).

[ryankemper]

I tested this out briefly, and found it useful but I echo what @sometimesfood noted about performance taking a major hit.

[booboo-at-gluga-de]

Added a switch now, so everybody experiencing problems with lagging prompts in large git repos on old hardware can switch off extended VCS infos easily.

Idea is to have extended VCS infos on by default (and easy to switch off if needed). Could that be a good compromise?
Or do you think we better should do it the other way round? Off by default and user needs to switch it on explicitly. (Which is way less convenient for the user in my opinion because in first place he does not even know about that feature.)

[sometimesfood]

Thanks!

Personally, I would much prefer this feature to be opt-in rather than opt-out, although I cannot vouch for the Grml community or the Grml team.

As stated above, there is a noticeable performance hit when cding to small repos on my idle 2017 MacBook Air, so this is not only a problem on low-end hardware:

[…] on my 2017 Macbook Air (macOS 10.13, zsh 5.3), the proposed changes render the Grml zshrc almost unusable (+600ms for "cd ~/src/grml-etc-core", similar for repos with <50 commits and a small number of files). On my OpenBSD boxes, the increased latency is quite noticeable as well. (If I quickly hit return five or six times in a row, I can actually watch zsh slowly catch up afterwards. […])

The aforementioned OpenBSD boxes are VMs on a relatively beefy server and are quite fast otherwise, so I would not call them "old hardware" either.

I understand your concerns regarding discoverability of the new VCS status feature, but I think it would be better to keep the Grml zshrc responsive by default.

[mika]

I'd definitely appreciate having such a feature available as easy to use as possible in our grml-zshrc. Currently I'm only using this feature in my own personal zsh configuration, using a ~/.zshrc.local which includes the following vcs_info customization:

https://gist.github.com/mika/a43caa86a8a35550c2f58c5b94793430

But it would be nice to have this available without such a large blob by default. :)

For me my configuration works reasonably well on a fast SSD, but on very large repositories (like git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git) there's a noticeable performance impact that will definitely be a problem for systems without fast storage (rotating disks, slow network mounts,....). Is there an easy way to enable this feature by default, but use a certain timeout (like 2 seconds?) to not block the shell if the git vcs information takes too long to load and then disable the feature (maybe with a vcs_timeout info or so in the prompt)?

We might also want to make characters like '!!', 'C', 'U', 'S' + 'P' be easily configurable (I'm using for example UTF-8 chars like ☂ and ≠)?

@ft I'd definitely appreciate your feedback to this! :)

[jkirk]

Hey,

just tested the raw zshrc of your PR.

At first it looks good:

• U is shown for untracked files
• C is shown for added but not committed files
• !! is shown for modified but not added files

jkirk@executor ~proj/misc/zshrc-git-test % git init
Initialized empty Git repository in /home/jkirk/projects/misc/zshrc-git-test/.git/
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master] % echo "test" >> testfile.txt
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|U] % git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        testfile.txt

nothing added to commit but untracked files present (use "git add" to track)
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|U] % git add testfile.txt 
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|C] % git status          
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   testfile.txt

jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|C] % git ci -m "initial commit"
[master (root-commit) 4897549] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 testfile.txt
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master] % echo "test2" >> testfile.txt
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|!!] %

But staged files do not seem to have an own status:

jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|!!] % git add testfile.txt
jkirk@executor ~proj/misc/zshrc-git-test (git)-[master|!!] % git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   testfile.txt

@mika uses ≠ for staged files.

[mika]

Oh wow, that was fast, thanks @booboo-at-gluga-de!
(Didn't manage to test this yet, as usual I'd appreciate @ft's as well as other @grml/team-grml-developers and grml-zshrc users' feedback :))

[evgeni]

In general I like having this extra info in my prompt (and personally I do, see https://github.com/evgeni/vcsh_zsh/blob/master/.zshrc.local), so +1 on the idea and this PR as a whole.

However, I prefer icons instead of letters, so my only question would be: how easily can a user customize this? Is it just a few calls to zstyle? Then I'm happy :)

[booboo-at-gluga-de]

@mika I like the idea of a timeout. Directly implemented this feature. I did set it to 2 sec by default but anyone can set an individual timeout by putting something like
GRML_VCS_TIMEOUT=4
into .zshrc.pre
@ALL Please test it. Hope this can help to ease the pain some of you are experiencing in big repos.

@jkirk, @mika, @evgeni Thanks for your great feedback on more detailed infos / more individual infos in the prompt. I really appreciate these ideas.
However I would like to try to get this basic version into a form which can be merged upstream.

In the next step after this I would like to work on enhancing the feature:

• Make the used characters / symbols easy to change.
• Make more status information available (currently there is e. g. no info in the prompt after you git delete <some_file>
• ...

And I promise it will not be too long until you see a pull request for these...

BTW - @mika: Being fast is quite easy right now. A concept we call holiday! :-)

[booboo-at-gluga-de]

@mika, @ft: There seem to be no more comments for now. How do we want to continue?

[ft]

booboo-at-gluga-de wrote:

@mika, @ft: There seem to be no more comments for now. How do we want to continue?

I'm afraid I've been much too busy at work lately. I didn't even have a cursory look at any of this, yet. Sorry about that. If the changes are not too intrusive, I might be able to do so at the beginning of the week.

[sometimesfood]

@booboo-at-gluga-de: Apparently there is a whole project dedicated to improving the performance of similar setups that might be interesting here as well: https://github.com/romkatv/gitstatus/

[LeSpocky]

Could #89 be of help for solving the performance issues of this PR?

[mika]

Is anyone interested in working on this for grml-etc-core's zshrc?