Binaries conflicting with existing commands creates error

[lukechilds]

Binaries conflicting with existing commands creates error

[lukechilds]

@SimenB Recreated this, working on a fix.

[lukechilds]

@SimenB Merged 👍

[lukechilds]

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 👍

[lukechilds]

@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. 4c61739

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.

[SimenB]

So gk won't work until nvm is loaded?

I'll test tonight

[lukechilds]

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.

[SimenB]

if nvm is loaded, then it works though. Why should lazy change that (other than the hit we get loading nvm the first time)?

[lukechilds]

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?

[SimenB]

@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