From: Johannes Sixt <j6t@kdbg.org>
To: Joey Hess <joey@kitenet.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/3] expanded hook api with stdio support
Date: Fri, 30 Dec 2011 19:04:55 +0100 [thread overview]
Message-ID: <4EFDFD47.2060700@kdbg.org> (raw)
In-Reply-To: <20111230171344.GA9667@gnu.kitenet.net>
Am 30.12.2011 18:13, schrieb Joey Hess:
> Johannes Sixt wrote:
>> IMHO, this is overengineered. I don't think that we need something like
>> this in the foreseeable future, particularly because such a pipeline or
>> multi-hook infrastructure can easily be constructed by the (single) hook
>> script itself.
>
> Junio seemed to think this was a good direction to move in and gave some
> examples in <7vlipz930t.fsf@alter.siamese.dyndns.org>
>
> Anyway, the minimum cases for run_hook_complex() to support are:
>
> * no stdin, no stdout
> * only stdin
> * stdin and stdout (needed for tweak-fetch)
> * only stdout (perhaps)
>
> The generator and reader members of struct hook allow the caller to
> easily specify which of these cases applies to a hook, and also provides
> a natural separation of the caller's stdin generation and stdout parsing
> code.
But as long as the generator only needs to generate a strbuf *and* only
one hook is run, there is no value to have it as a callback; the caller
can just specify the strbuf itself, run_hook_* does not need to care how
it was generated.
I can see some value in a reader callback to avoid allocating yet
another strbuf.
> ... The data member could
> be eliminated and global variables used by callers that need that,
> but I prefer designs that don't require global variables.
Absolutely.
>>> + If the hook does not exist or is not executable, the return value
>>> + will be zero.
>>> + If it is executable, the hook will be executed and the exit
>>> + status of the hook is returned.
>>
>> What is the rationale for these error modes? It is as if a non-existent
>> or non-executable hook counts as 'success'. (I'm not saying that this
>> would be wrong, I'm just asking.)
>
> They are identical to how run_hook already works.
> A non-existant/non-executable hook *is* a valid configuration,
> indeed it's the most likely configuration.
So, it is so that the caller does not itself have to check whether a
hook exists. That may be worth a word in the API documentation.
-- Hannes
next prev parent reply other threads:[~2011-12-30 18:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-30 1:07 extended hook api and tweak-fetch hook Joey Hess
2011-12-30 1:07 ` [PATCH 1/3] expanded hook api with stdio support Joey Hess
2011-12-30 9:47 ` Johannes Sixt
2011-12-30 17:13 ` Joey Hess
2011-12-30 18:04 ` Johannes Sixt [this message]
2012-01-03 19:53 ` Junio C Hamano
2012-01-03 20:06 ` Jeff King
2012-01-03 21:44 ` Junio C Hamano
2011-12-30 1:07 ` [PATCH 2/3] preparations for tweak-fetch hook Joey Hess
2011-12-30 1:07 ` [PATCH 3/3] add " Joey Hess
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=4EFDFD47.2060700@kdbg.org \
--to=j6t@kdbg.org \
--cc=git@vger.kernel.org \
--cc=joey@kitenet.net \
/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).