From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [PATCH v4] transport-helper: report errors properly
Date: Mon, 8 Apr 2013 15:28:29 -0400 [thread overview]
Message-ID: <20130408192829.GC7337@sigill.intra.peff.net> (raw)
In-Reply-To: <1365432004-20132-1-git-send-email-felipe.contreras@gmail.com>
On Mon, Apr 08, 2013 at 09:40:04AM -0500, Felipe Contreras wrote:
> If a push fails because the remote-helper died (with fast-export), the
> user won't see any error message. So let's add one.
>
> At the same time lets add tests to ensure this error is reported, and
> while we are at it, check the error from fast-import
Thanks, I think this patch is definitely the right direction.
It seems like there is a lot of back-story that had to be clarified
during the review/discussion. Is there a reason not to summarize it here
so later readers of this commit are enlightened?
I'm thinking something like:
If a push fails because the remote-helper died (with fast-export), the
user does not see any error message. We do correctly die with a failed
exit code, as we notice that the helper has died while reading back
the ref status from the helper. However, we don't print any message.
This is OK if the helper itself printed a useful error message, but we
cannot count on that; let's let the user know that the helper failed.
In the long run, it may make more sense to propagate the error back up
to push, so that it can present the usual status table and give a
nicer message. But this is a much simpler fix that can help
immediately.
While we're adding tests, let's also confirm that the remote-helper
dying is also detect when importing refs. We currently do so robustly
when the helper uses the "done" feature (and that is what we test). We
cannot do so reliably when the helper does not use the "done" feature,
but it is not even worth testing; the right solution is for the helper
to start using "done".
> export)
> + if test -n "$GIT_REMOTE_TESTGIT_FAILURE"
> + then
> + sleep 1 # don't let fast-export get SIGPIPE
> + exit 1
> + fi
We can do away with this sleep with:
while read line; do
test "$line" = "done" && break
done
The version I posted yesterday had both the read and the sleep, but the
sleep was only necessary there to demonstrate the race with
check_command.
> +# We sleep to give fast-export a chance to catch the SIGPIPE
> +test_expect_success 'proper failure checks for pushing' '
I think we can drop this comment now, right?
-Peff
next prev parent reply other threads:[~2013-04-08 19:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-08 14:40 [PATCH v4] transport-helper: report errors properly Felipe Contreras
2013-04-08 18:20 ` Sverre Rabbelier
2013-04-08 19:30 ` Jeff King
2013-04-08 19:28 ` Jeff King [this message]
2013-04-09 21:38 ` Thomas Rast
2013-04-09 21:50 ` Jeff King
2013-04-10 21:13 ` [PATCH v5 0/2] reporting transport helper errors Jeff King
2013-04-10 21:15 ` [PATCH 1/2] transport-helper: report errors properly Jeff King
2013-04-10 21:22 ` Sverre Rabbelier
2013-04-10 21:46 ` Eric Sunshine
2013-04-11 13:22 ` Felipe Contreras
2013-04-11 16:18 ` Jeff King
2013-04-11 16:49 ` Felipe Contreras
2013-04-11 16:59 ` Jeff King
2013-04-11 17:57 ` Felipe Contreras
2013-04-11 18:49 ` Junio C Hamano
2013-04-11 21:35 ` Felipe Contreras
2013-04-11 18:44 ` Junio C Hamano
2013-04-11 21:21 ` Felipe Contreras
2013-04-11 23:05 ` Junio C Hamano
2013-04-13 5:42 ` Felipe Contreras
2013-04-13 6:00 ` Jeff King
2013-04-13 6:43 ` Felipe Contreras
2013-04-14 5:23 ` Junio C Hamano
2013-04-14 15:54 ` Felipe Contreras
2013-04-10 21:16 ` [PATCH 2/2] transport-helper: mention helper name when it dies Jeff King
2013-04-10 21:23 ` Sverre Rabbelier
2013-04-10 21:28 ` Jeff King
2013-04-10 21:35 ` Sverre Rabbelier
2013-04-10 23:13 ` [PATCH v4] transport-helper: report errors properly rh
2013-04-11 3:39 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130408192829.GC7337@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=srabbelier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).