Clone as fallback is not working if fetch fails on non-first-clone jobs

[rassie]

If I'm reading the code correctly, there is an assumption that git fetch can only fail if the target directory is missing, i.e. this is first-clone time. However, should fetch fail for whatever reason while the target directory exists (e.g. wrong credentials), it is not deleted to make room for a clone.

[jonasmalacofilho]

That's true. Though I'm not sure if the cache (target) directory should be deleted.

I think such a failure should be reported to the end user, as it's probably a network error or other non-recoverable problem (authentication has already succeeded for control flow to reach this point).

Does this make sense?

[rassie]

Yes, report it to the user and abort the request. The authentication problem has been two-fold until now: you have been authenticating to upstream with the credentials you've got via the request, but actually fetched newest revisions with the credentials saved in .git/config. This shouldn't be the case anymore with my patch for #7, but there might be some edge cases which are not covered.

Either way: error message and abort should be good enough.