TypeError is thrown during clone when permission is denied to repository on BitBucket

A TypeError is thrown during clone under the following circumstances:

• The repository is hosted on Bitbucket.
• The credentials (user:password) must be valid for an existing account on the server.
• The account must not have access permission to the repository.

The problem seems to be in the capabilities negotiation.

Here’s the stack from the error:

Caused by: TypeError: Cannot read property 'split' of undefined
    at parseRefsAdResponse (/mnt/c/Users/ecroc/git/external/antora/node_modules/isomorphic-git/dist/for-node/isomorphic-git/index.js:5123:20)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Function.discover (/mnt/c/Users/ecroc/git/external/antora/node_modules/isomorphic-git/dist/for-node/isomorphic-git/index.js:5241:26)
    at async fetchPackfile (/mnt/c/Users/ecroc/git/external/antora/node_modules/isomorphic-git/dist/for-node/isomorphic-git/index.js:6041:22)
    at async fetch (/mnt/c/Users/ecroc/git/external/antora/node_modules/isomorphic-git/dist/for-node/isomorphic-git/index.js:5902:22)
    at async Object.clone (/mnt/c/Users/ecroc/git/external/antora/node_modules/isomorphic-git/dist/for-node/isomorphic-git/index.js:6413:42)

[djencks]

My proposal does include the entire unparseable line. While not particularly useful in the particular case Ec Roc found, indicating why the response is unparseable could be useful if for instance a line arrives with two adjacent spaces instead of one. Including the entire response or the response up to and including the problem part would be great, but I don’t immediately see how to do that efficiently. If the error occurs on the 1500th ref the first few hundred characters wouldn’t include it. Having a special error seems like a great idea. How about including the bad line in the message along with the problem, and the entire response in error.data.response? If it’s something like a double space, it’s going to be much easier to see if you know what line it’s in.

[mojavelinux]

@djencks I don’t think we’re disagreeing. If the line is malformed, isomorphic-git should throw an error saying so and preserve the line so that it can be inspected.

While the error Ec got was a permission error, it was not sent by the server in the correct way. A permission error should be a 403 error. Instead, the server returned a 200 status and stuffed the error message into the body. In that case, isomorphic-git should simply say “no way, that’s a bad response” and then pass that response along as the exhibit.