Closed SimenB closed 8 years ago
Hmmn, definitely an issue with lazy loading.
I'm pretty busy this weekend, I'm probably not going to get a chance to look at this until Monday. Disabling lazy loading should resolve the issue for now.
I'll let you know when it's sorted 👍
@SimenB Recreated this, working on a fix.
@SimenB Ok, I'm now checking if any commands exist globally before setting the lazy load functions. If they already exist, those commands are ignored. https://github.com/lukechilds/zsh-nvm/commit/4c6173938c2a1df130d0e98cd4a23d355ba0e0ab
Can you checkout the fix-alias-bug branch and let me know if that resolves the issue for you? If it does I'll merge into master.
So gk
won't work until nvm is loaded?
I'll test tonight
No gk
won't work at all because the alias overrides it. That's how it would work without lazy loading. You'll need to remove your gk
alias if you want to use the gk
greenkeeper binary.
if nvm is loaded, then it works though. Why should lazy change that (other than the hit we get loading nvm the first time)?
Hmmn, it shouldn't do. The alias should be overwriting the function. That's how it's working on my dev VM.
If you disable lazy loading what happens when you run gk
? Do you run gitk
or Greenkeeper?
@lukechilds OK, tested now, and you are correct! It's gitk which is run when lazy is false.
And your branch fixes the issue 😄
I had to set lazy to false btw, it seems to default to true. That hasn't happened before, unsure why it happened now
@SimenB Merged 👍
Such as greenkeeper, which has the short form
gk
, which on my machine is aliased (gk: aliased to \gitk --all --branches
).I then get a warning when nvm loads
gitk:unset:1: no such hash table element: gk
.Worse is trying to use
gk
makes it loop infinitely.etc.
This is using LAZY, tbw.