Slow to startup on fresh boot of macOS about fish-shell

[faho]

For context: xcode ships some terrible shims that take ages to set up so the first git call takes ages.

We kick off git in the background and then check if the xcrun cache-path exists to determine whether it's set up or not.

Apparently that got changed so that check is no longer working - wouldn't be the first time apple broke something around us (see the apropos saga).

I have no idea what the correct check now is and I don't have a mac to check, so I'm not going to be of help here.

My recommendation for now is to install a git outside of xcode and let that take precedence in $PATH.

[mqudsi]

For posterity and reference, can you do a which git, ldd git, and find / -samefile (which git) and share the outputs?

[faho]

Make that command -s git and find / -samefile (command -s git)

[nixpulvis]

@mqudsi

$ command -s git
/usr/bin/git

$ otool -L (command -s git)
/usr/bin/git:
	/usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)

$ find / -samefile (command -s git)
/usr/bin/indent
/usr/bin/xml2man
/usr/bin/gcov
/usr/bin/g++
/usr/bin/libtool
/usr/bin/Rez
/usr/bin/ctags
/usr/bin/c++
/usr/bin/strings
/usr/bin/gm4
/usr/bin/clang
/usr/bin/git-receive-pack
/usr/bin/objdump
/usr/bin/c99
/usr/bin/c++filt
/usr/bin/strip
/usr/bin/python3
/usr/bin/clangd
/usr/bin/lex
/usr/bin/ctf_insert
/usr/bin/sourcekit-lsp
/usr/bin/pip3
/usr/bin/ld
/usr/bin/lldb
/usr/bin/pagestuff
/usr/bin/headerdoc2html
/usr/bin/hdxml2manxml
/usr/bin/resolveLinks
/usr/bin/git-upload-archive
/usr/bin/gcc
/usr/bin/segedit
/usr/bin/dwarfdump
/usr/bin/gperf
/usr/bin/vtool
/usr/bin/dsymutil
/usr/bin/SplitForks
/usr/bin/rpcgen
/usr/bin/otool
/usr/bin/DeRez
/usr/bin/codesign_allocate
/usr/bin/cpp
/usr/bin/swift
/usr/bin/make
/usr/bin/nm
/usr/bin/flex++
/usr/bin/llvm-gcc
/usr/bin/ar
/usr/bin/unifdef
/usr/bin/lipo
/usr/bin/clang++
/usr/bin/m4
/usr/bin/asa
/usr/bin/swiftc
/usr/bin/as
/usr/bin/gnumake
/usr/bin/ResMerger
/usr/bin/bm4
/usr/bin/git-shell
/usr/bin/cc
/usr/bin/unifdefall
/usr/bin/size
/usr/bin/llvm-g++
/usr/bin/yacc
/usr/bin/c89
/usr/bin/git-upload-pack
/usr/bin/lorder
/usr/bin/ranlib
/usr/bin/flex
/usr/bin/SetFile
/usr/bin/nmedit
/usr/bin/bison
/usr/bin/mig
/usr/bin/GetFileInfo
/usr/bin/git
/usr/bin/install_name_tool
/usr/bin/cmpdylib
/usr/bin/gatherheaderdoc
...

[mqudsi]

Ok, we're in luck and as I suspected it's a hard link to a single binary that does this for a lot of other stuff.
Can you post the un-truncated list of find output as an attachment?

[mqudsi]

Also, please attach the full profile so we can see in which order the commands are executed and how long specific git invocations take.

[nixpulvis]

I don't think my truncation missed anything, I simply stopped the find once it started returning permission errors searching folders this user doesn't have access to.

And here's the full profile: https://paste.rs/vBWhf.txt

[mqudsi]

Ok, thanks.

Going through the profile, it seems that the logic behind a77bc70 no longer holds up. Specifically, we kick off a backgrounded git --version task, but then the first time we run xcrun --show-cache-path it returns something that passes the path is ... check. We take that to mean that the cache has been populated and subsequent git invocations will be quick, but immediately thereafter when we try to use git rev-parse ... for real, it hangs for 12 seconds. Subsequent invocations are much faster, so it's not probably it's because the cache isn't being used; meaning most likely our assumption that xcrun --show-cache-path returning a valid path implies a git invocation will be quick is incorrect.

I don't see why we need to do this dance with xcrun at all; maybe it's only because we can't background fish functions? It's an ugly hack, but instead of backgrounding git --version then checking/waiting for xcrun --show-cache-path to return a valid path, why don't we just do the following:

function __fish_is_git_ready
    # Specifically use /tmp/ because that's where the xcrun cache is stored and
    # it is cleared on startup. We have no guarantee that our normal fish temp
    # directory would be cleared on startup.
    if ! path /tmp/__fish_git_xcrun_primed
        # Ignore this race condition; it's unlikely to happen and OK if it does
        if ! path is /tmp/__fish_git_xcrun_started
            touch /tmp/__fish_git_xcrun_started
            sh -c 'git --version && touch /tmp/__fish_git_xcrun_primed' &
            disown
        end
        return 1
    end
    functions -e __fish_is_git_ready
    return 0
end

# In fish_git_prompt:

# if Darwin
    if functions -e __fish_is_git_ready && not __fish_is_git_ready
        return 1
    end
# endif

# Carry on