| commit | cdaa4e98ca56586f78a455bd624457248347a56d | |
| author | Jeff King <peff@peff.net> | |
| Wed, 9 Jul 2014 21:47:20 +0000 (9 17:47 -0400) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Thu, 10 Jul 2014 17:54:22 +0000 (10 10:54 -0700) | ||
| tree | 1f69628ae28d8eed9d7453d5c3916bdc44e33ed4 | treesnapshot (tar.gz zip) |
| parent | b725b270d1474819d46161909416ef73ba2170ff | commitdiff |
remote-curl: mark helper-protocol errors more clearly
When we encounter an error in remote-curl, we generally just
report it to stderr. There is no need for the user to care
that the "could not connect to server" error was generated
by git-remote-https rather than a function in the parent
git-fetch process.
However, when the error is in the protocol between git and
the helper, it makes sense to clearly identify which side is
complaining. These cases shouldn't ever happen, but when
they do, we can make them less confusing by being more
verbose.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we encounter an error in remote-curl, we generally just
report it to stderr. There is no need for the user to care
that the "could not connect to server" error was generated
by git-remote-https rather than a function in the parent
git-fetch process.
However, when the error is in the protocol between git and
the helper, it makes sense to clearly identify which side is
complaining. These cases shouldn't ever happen, but when
they do, we can make them less confusing by being more
verbose.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| remote-curl.c | diffblobblamehistory |