Details
-
Suggestion
-
Resolution: Fixed
-
None
-
None
Description
Currently, errors output by git when git clone or git pull or other commands fail, over HTTP(S), are not very useful. The user may get a status code, but that's about all. This is likely to be a support issue, especially for cases where a user has been CAPTCHA'd; they have to logout and back in via the UI in order to find out what's wrong.
One possible approach to working around this problem is to display banners in the web interface when things are going sideways (and in some cases we've made changes to do that), but it would be better if client's got useful error messages back from git instead.
After dumpster diving through git's codebase, it appears it actually is possible to send back error messages during the discovery phase, with git's "smart" HTTP protocol. I'm not sure about whether it's possible to send them back during the git-upload-pack phase, but even if we can only send them during discovery it's still a nice usability improvement. This is especially true for CAPTCHA, which will never make it past the discovery phase.
Another advantage of sending nice error messages is that it also prevents git from automatically trying to fall back to the "dumb" protocol when there's an error.