Local packages named by *.git extension are handled as remote sources instead local ones.

[ChristophAtAdlos]

Do you want to request a feature or report a bug?
This is a bug report.

What is the current behavior?
In package.json:
"myBackendModule": "file:../myBackendModule.git"

C:\Git\myFrontendModule.git>yarn
yarn install v0.24.5
[1/4] Resolving packages...
error Command failed.
Exit code: 128
Command: git
Arguments: clone file:../myBackendModule.git C:\Users\christoph\AppData\Local\Yarn\cache\v1\.tmp\534d3fc1a8a74d07d486ff305cbd21f0
Directory: C:\Git\myFrontendModule.git
Output:
Cloning into 'C:\Users\christoph\AppData\Local\Yarn\cache\v1\.tmp\534d3fc1a8a74d07d486ff305cbd21f0'...
ssh: Could not resolve hostname file: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Renaming the folder to myBackendModule.got, it works. But on next checkout, it fails again, because the repos are named *.git.
If the current behavior is a bug, please provide the steps to reproduce.
Link a local package which name has git as extension.
In our enterprise, the git extension is default to show that the package comes from our git repository.

What is the expected behavior?
If the path is declared by "file" or if it's a relative path without server name, dont use the remote method but the local file access.

Please mention your node.js, yarn and operating system version.

node --version
v4.6.1
npm upgrade --global yarn
yarn --version
yarn v0.24.5

[titarta]

I'm going to try to work on this issue on the next week.

[rafaeldamasceno]

Hey, I'm also one other person that's helping with the bug. The problem seems to be with /util/git.js. However, I can't reproduce the bug in the state that the reported sent it. Now, it seems that it tries to run ls-remote first. We've since tried to fix it, but it seems we're not getting consistent results.

See here: https://github.com/rafaeldamasceno/yarn/commit/d17a77b1d8bce6e209a309ea176e6a1a9e853b70

It seems that with these changes, we now can successfully clone the repository, but there were some instances where we had some errors and we aren't quite sure how to fix them. Also, it seems that after yarn caches the repository, it doesn't quite verify if it has been updated. Maybe this is intended behaviour and it only checks for versions bumps?

We'd like some input before we submit a pull request.

[tiagoboldt]

Isn't this issue closed by the above PR?

[rafaeldamasceno]

@tiagoboldt the above PR is for my own fork's branch. #5026 is still pending review for merging into master.