git prompt issues in fish 3.0

[azdanov]

After updating to latest fish 3.0 the git prompt started to misbehave.

1. Full path is shown for the second time.

2. Once line length is exceeded the cursor becomes >.

Is it my setup being faulty or 3.0 broke something?

[bobthecow]

It wouldn’t surprise me if it is 3.0. I’ll take a look next week when I’m back to my computer :)

[bobthecow]

The > is just how fish works when your prompt is too long.

Including your home directory is weird, but, based on the two strings, my guess is it's because of Projects vs projects. Why are they different cases?

[azdanov]

The > is just how fish works when your prompt is too long.

Didn't know this.

Including your home directory is weird, but, based on the two strings, my guess is it's because of Projects vs projects. Why are they different cases?

Original is Projects, no idea why it's lowercased and repeated.

[azdanov]

I've fiddled around a little bit and after renaming Projects to projects everything started to work as before the update.

Closing since the issue is resolved.

[bobthecow]

it’s still weird that the case is different. i don’t love that the answer is “change your filesystem” :-/

[z3ntu]

I also see the "full path shown as path in git repository" Abbreviated project-relative path issue on Linux with an ext4 filesystem

[bobthecow]

what do git rev-parse --show-toplevel and pwd show in a directory with this issue?

[z3ntu]

Found a way to easily reproduce the issue:

cd /tmp
mkdir dir1
ln -s dir1 dir2
cd dir2
git init

$ git rev-parse --show-toplevel
/tmp/dir1
$ pwd
/tmp/dir2

[bobthecow]

I've updated the project-relative path segment to support symlinks. This should resolve all issues, both with symlinks as well as case-insensitive filesystems (which I believe was the initial issue here).

Confirmed by testing with all possible variants of symlinks and real directories:

[azdanov]

@bobthecow Nice, it does seem to work as before. Thanks!

[z3ntu]

Found another issue:

mkdir -p /tmp/dir1/somedir
ln -s /tmp/dir1/somedir /tmp/somedir
cd /tmp/dir1
git init
cd /tmp/somedir
# no git prompt

[bobthecow]

@z3ntu thanks, I'll take a look.

[rousseldenis]

It seems I have quite the same issue but fish 2.7.1

And vertical lines appear with the >

[bobthecow]

@rousseldenis I'm not sure I understand what issue you're having, other than the vertical lines.

[rousseldenis]

@bobthecow I recently get a fresh install and everything seems ok.

[z3ntu]

I think also git add tab completion is broken, meaning press tab when having git add in the prompt, doesn't show anything (EDIT: at least in some cases?)

another edit: found this bug in the fish repo that fixed that issue fish-shell/fish-shell#5648

[bcbwatt]

I am having issues where often the prompt will not show at all until I cd back into the same directory.

By this I mean that sometimes I enter a git directory and the git prompt shows as expected. It often does not stay if I cd into a subdirectory (it disappears completely). cd'ing to the root will fix this most of the time, but not always; sometimes I just cannot get the git prompt to show in the root dir at all.

Initially I thought the flag for enabling / disabling worktree support affected this, but after some testing it makes no difference.

It was all working as expected for me until I did a clean reinstall - previously I was using a fish 2.x version and a much older revison of bobthefish.

EDIT: I have just realised that the issues occur when I cd into /users/name/git/... rather than /Users/name/git/... - it seems that the issue is because of the case difference (but I am on a mac so the filesystem does not care about case).

[bobthecow]

@ben-watt-es yeah, fish 3 changed the way pwd works, so it gets a little weird with case insensitive filesystems. Are you running the latest bobthefish? It should be worked around in 4ccdd7b

[azdanov]

@bobthecow I've had the same issues where cding into /Users/azdanov/projects/node instead of /Users/azdanov/Projects/node caused some issues, with Git indicator in particular. Took me a while to figure out it was case sensitivity all along.

And thanks for your hard work!

[bobthecow]

All permutations of this should now be resolved. Feel free to re-open if you run into it again :)

[z3ntu]

That fixes my use case at least :)

What seems to be a bit not-exactly-intuitive behavior is that the prompt shows the "real" (=resolved) parent directory of your current one, so for example doing cd .. is not very intuitive as you're not getting into the directory you're expecting to go ;) Just a minor complaint though

[bobthecow]

Yeah, I don’t love it, but I didn’t love the alternatives either.

When we interact with external services like git, or hg, or whatever, which bobthefish does a lot of, we need to talk about paths in terms of things they understand. And if we only use resolved paths when talking to external services, it gets weird mapping them back to the fishy paths we use internally. So I went with always referring to things by canonical paths, because it was less awful.

The other option, which I poked at but didn’t get very far, would be to always refer to things by their internal paths, and do try to map external services’ idea of paths back into what fish things the pwd is. If you wanna take a shot at it, I’d be happy to entertain a pull request :)

[Climax777]

Mine still doesn't work with bobthefish @bobthecow

Oh My Fish version:   6
OS type:              Linux
Fish version:         fish, version 3.0.2
Git version:          git version 2.20.1
Git core.autocrlf:    no

[Climax777]

It seems to be related to the c++ part of the path. Moving my project to cpp for example works, but adding a + to any folder in the path breaks it for me.

[Climax777]

Could this be related to git or is the output of this correct?

$ git rev-parse --show-toplevel
/home/pieter/Documents/Programming/c++/secuvue-agent
$ pwd
/home/pieter/Documents/Programming/c++/secuvue-agent/build