empty git status (:|✔) shows up even in non git directories

[choufleur]

The command
RPROMPT='$(git_super_status)'
in my .zshrc has for effect that in a non git directory I get (:|✔)

This wasn't the case until my recent switch to fedora 26. Any idea on how to fix this issue ?

[apoutchika]

I have same issue on fresh install of debian 9...

[456Xander]

I also have this issue on Manjaro

[soner89]

I have the same issue on ArchLinux. Every directory have (:|✔) in the prompt, even if it's not a git initialized directory.

[nimag42]

It happens because the python script doesn't find "fatal: Not a git repository" in error message and doesn't exit as author's designed it (line 15 in gitstatus.py)
For example if your system is set on another language (french for me), the error message doesn't contain the string.

If your system is in english and you still have the problem, can you print the result of git status in a non-git folder to debug ?

A simple fix could be this :

diff --git a/zshrc.sh b/zshrc.sh
index 87b43fa..e513393 100644
--- a/zshrc.sh
+++ b/zshrc.sh
@@ -63,7 +63,8 @@ function update_current_git_vars() {
 
 git_super_status() {
        precmd_update_git_vars
-    if [ -n "$__CURRENT_GIT_STATUS" ]; then
+    if [ "$GIT_BRANCH" != ":" ]; then
          STATUS="$ZSH_THEME_GIT_PROMPT_PREFIX$ZSH_THEME_GIT_PROMPT_BRANCH$GIT_BRANCH%{${reset_color}%}"
          if [ "$GIT_BEHIND" -ne "0" ]; then
                  STATUS="$STATUS$ZSH_THEME_GIT_PROMPT_BEHIND$GIT_BEHIND%{${reset_color}%}"

@olivierverdier, would you accept such a fix, or isn't it clean enough for you ? (I haven't tested it to see if this introduces new bugs...)

[choufleur]

@nimag42 your guessed right : my system is set on French as well.

[QuinnyPig]

Just found this; there was a regression as well that changed the case. #117 fixes this on my (English) system.

[jonbarksdale]

I'm seeing this again as well.

[Segaja]

My suggested fix for this:

diff --git a/gitstatus.py b/gitstatus.py
index d944fd4..28bdad4 100755
--- a/gitstatus.py
+++ b/gitstatus.py
@@ -12,7 +12,7 @@ branch, error = gitsym.communicate()
 
 error_string = error.decode('utf-8')
 
-if 'fatal: Not a git repository' in error_string:
+if 'fatal: not a git repository' in error_string.lower():
        sys.exit(0)
 
 branch = branch.decode("utf-8").strip()[11:]

That way the system doesn't care in which case the git binary returns this error.

[fam4r]

@nimag42 solves for me
@QuinnyPig @Segaja does not solve for me

Loaded with zgen in Arch Linux

[Segaja]

check what the output of git symbolic-ref HEAD is on your system. I see this as an error that the python script doesn't realize there is no repository.

[fam4r]

@Segaja
In a non-git folder the output is:

git symbolic-ref HEAD
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

[Segaja]

Hm this should work. did you apply the entire change? the lowercasing of the first string and the .lower() function at the end?

[fam4r]

Hi @Segaja ,

I used @QuinnyPig patch (branch in his fork) in my zgen load, which changes exactely what you said.

[Segaja]

That is not enough. According to #117 he only added the .lower() call at the end, but the "N" of "fatal: Not a git repository" is still uppercase.

So essentially this line checks if the string "fatal: Not a git repository" is present in the output of the git symbolic-ref HEAD command. But for some reason the cases of the words changed, that is why I propose to lowercase the command output (... in error_string.lower(): but then also lowercase the needle you search: "fatal: not a git repository".

[Segaja]

Upon thinking more about this and reading above that some people have non-english system, maybe it makes more sense not to check the error string, but the return code of the command.
I forked the project and created #119 to push my changes back into this master.

[nimag42]

@Segaja clever thought, nice seeing someone that understand english is not the only language on earth :p

[fam4r]

@Segaja your newer solution that checks for the error code works for me, thank you!

[madnight]

Can we merge a fix here or is this project dead (last file change 2 years ago)?

By the way another fix without changing the source code is to set the option: GIT_PROMPT_EXECUTABLE="haskell"

[Kynde]

Ouch, this does seem dead/dying. Another ancient issue and still not fixed.

Someone should fork this. Stash support and fixes would be nice. Too many open PRs.

[fam4r]

@Kynde
I forked and implemented both working (for me) solutions for that problem in two different branches.

fam4r/zsh-git-prompt

I'm not going to fork and mantain that project, if someone wants to do that, please tell us!

[starcraftman]

Hmmm, well this is disappointing that the project not really being maintained. I don't write Haskell really, do know a fair bit of python and shells. I am poking around now because like others my prompt stopped behaving well with recent changes, had to fix up my fork.

@fam4r What did you have in mind, we just make an issue and direct people to another fork?

You guys can see mine at: https://github.com/starcraftman/zsh-git-prompt

It is unfortunately a bit of a faux pas in its current state. I forked 4 years ago and haven't looked in much. I wanted parity with bash-git-prompt both thematically and functionally. I may have been rather ham fisted and less experienced. I suppose the main change is a large refactor of gitstatus.py recently and I deleted the Haskell stuff a while ago, hehe. Probably shouldn't have.

Current state isn't super ideal, I should probably tidy it up and replay the good bits over current Olivier master. I suppose not deleting the Haskell stuff would help too. Without a Haskell collaborator it will likely languish behind on changes though.

[starcraftman]

@olivierverdier Are you about or looking for a maintainer?

[madnight]

@starcraftman Haskell fan over here, i would fix the Haskell part, if someone wants to maintain a fork and work through all open issues and pull requests

[starcraftman]

I have since rebased my master to align with this project and replayed my changes into a single commit on top. So should be much more coherent if anyone looking. It is a lot of edited lines, I'll have to check more thoroughly that everything still works as expected. Don't normally try the Haskell implementation.

@madnight Thanks, will keep that in mind. I suppose depends now if Olivier is about to deputize a maintainer. Will wait a while. Otherwise I guess we can just work on my fork. In that case unfortunately we'd have low visibility.

[fam4r]

@starcraftman yes, it can be a good way, the problem comes when other people make new issues: the one that points to new repo will be not be so longer visible.

In my (little) experience I saw something like that: https://github.com/eBrnd/i3lock-color/blob/master/README.md.

Putting a message in first lines of README could be a good way to let people follow right directions to the new repo/fork.

If @olivierverdier is ok with that, obviously.

[madnight]

Otherwise, if @olivierverdier cannot do that for some reason, then just fix all existing bugs and do MR's and put a link in this repo issues to the fork, where those issues have been fixed. Monitor this repo issues and on any new issue put a link to our maintained fork. It takes a while, but after some time people will start to accept the fork as new upstream, even more so when this repo becomes fundamentally broken (unusable) in the future.

[robeirne]

Quick fix:
In zshrc.sh add one line in the git_super_status() function beneath the call to precmd_update_git_vars:

git_super_status() {
  precmd_update_git_vars
  [[ "$GIT_BRANCH" == ":" ]] && return
...

Of course, if you have a branch named ":" your git prompt won't print.

[starcraftman]

@madnight Yeah, that seems like what I'll have to do. Olivier doesn't seem responsive. Quite annoying. Github needs a better solution to dead original repositories. Though git is decentralized, their site only really promotes originals. It happens often and is much worse in larger more elaborate projects. Sadly looking at some old issues on github they've yet to agree on a plan.

I'll make some notes in my forked readme on my changes and that I can atm only personally guarantee the python interface. If you want to assist, I've added a few things to the python version that should be mirrored to Haskell. See issue 5 on my fork. Basically just points 8-10 and a small change on behaviour of 1 for customization.

@robeirne If you just want a working prompt this has already been fixed on my active fork, along with some other extra features like stashed support and displaying the upstream. See here: https://github.com/starcraftman/zsh-git-prompt To be clear I'll be maintaining mine.

Please star it for visibility. I'll have to make some formal announcement eventually.

[starcraftman]

Announcement made, hopefully other people make use of the fork.

[woolson]

@Segaja thank you, it's worked. ps: it happened after macOS(10.13.6) installed command line tools update today.

[joeblubaugh]

@starcraftman I see you haven't been maintaining your fork either - should we hand it off to someone else?