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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.