git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] allowing hooks to ignore input?
Date: Sat, 13 Sep 2014 10:19:18 +0200	[thread overview]
Message-ID: <5413FE06.1020901@kdbg.org> (raw)
In-Reply-To: <xmqqzje48nh4.fsf@gitster.dls.corp.google.com>

Am 13.09.2014 um 00:48 schrieb Junio C Hamano:
> The pre-receive and post-receive hooks were designed to be an
> improvement over old style update and post-update hooks that used to
> take the update information on the command line and were limited by
> the command line length limit.  They take the same information from
> their standard input.  It has been mandatory for these new style
> hooks to consume the update information fully from the standard
> input stream.  Otherwise, they would risk killing the receive-pack
> process via SIGPIPE.
> 
> This is easy, and it has already been done by existing hooks that
> are written correctly, to work around, if a hook does not want to
> look at all the information, by sending its standard input to
> /dev/null (perhaps a niche use of hook might need to know only the
> fact that a push was made, without having to know what objects have
> been pushed to update which refs).
> 
> However, because there is no good way to consistently fail hooks
> that do not consume the input fully, it can lead to a hard to
> diagnose "once in a blue moon" phantom failure.
> 
> I wonder if this "you must consume the input fully", which is a
> mandate that is not enforced strictly, is not helping us to catch
> mistakes in hooks more than it is hurting us.  Perhaps we can do
> something like the attached patch to make it optional for them to
> read the input we feed?
> 
> I dunno.
> 
>  builtin/receive-pack.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index 30560a7..9d9d16d 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -17,6 +17,7 @@
>  #include "version.h"
>  #include "tag.h"
>  #include "gpg-interface.h"
> +#include "sigchain.h"
>  
>  static const char receive_pack_usage[] = "git receive-pack <git-dir>";
>  
> @@ -500,6 +501,8 @@ static int run_and_feed_hook(const char *hook_name, feed_fn feed, void *feed_sta
>  		return code;
>  	}
>  
> +	sigchain_push(SIGPIPE, SIG_IGN);
> +
>  	while (1) {
>  		const char *buf;
>  		size_t n;
> @@ -511,6 +514,9 @@ static int run_and_feed_hook(const char *hook_name, feed_fn feed, void *feed_sta
>  	close(proc.in);
>  	if (use_sideband)
>  		finish_async(&muxer);
> +
> +	sigchain_pop(SIGPIPE);
> +
>  	return finish_command(&proc);
>  }

I think this is a good move. Hooks are written by users, who sometimes
are not clueful enough.

But what do our writers do when they fail with EPIPE? Die? If so, this
patch alone is not sufficient.

-- Hannes

  reply	other threads:[~2014-09-13  8:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12 22:48 [RFC] allowing hooks to ignore input? Junio C Hamano
2014-09-13  8:19 ` Johannes Sixt [this message]
2014-09-15 17:51   ` Junio C Hamano
2014-09-16 22:27   ` Junio C Hamano
2014-09-18 11:14     ` 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=5413FE06.1020901@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).