From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git <git@vger.kernel.org>
Subject: Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*
Date: Tue, 26 Apr 2016 14:52:02 -0700 [thread overview]
Message-ID: <xmqq60v4don1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=H4wacPhHjFbQ@mail.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Tue, 26 Apr 2016 12:58:04 +0200")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> I think it's fair enough to say that if we had this facility this
> would be good enough:
>
> * Your hooks are executed in glob() order, local .git first, then /etc/git/...
>
> * If it's a hook like pre-commit that can reject something the first
> hook to fail short-circuits. I.e. none of the rest get executed.
>
> * If it's not a hook like that e.g. post-commit all of the hooks will
> get executed.
>
> * If you need anything more complex you can just wrap your hooks in
> your own shellscript.
>
> I.e. it takes care of the common case where:
>
> * You just want to execute N hooks and don't want to write a wrapper.
>
> * For pre-* hooks the common case is it doesn't matter /what/
> rejected things, just that it gets rejected, e.g. for pre-receive.
> Also if you care about performance you can order them in
> cheapest-first order.
Stop using the word "common" to describe what is not demonstratably
"common".
The above only covers a very limited subset of the use cases, which
is the two bullet points above (one of them i.e. "I do not bother to
write a wrapper" is not even a valid use case). That may be a good
starting point, but it is so simple that can be done with a wrapper
with several lines at most. So I am not sympathetic to that line of
reasoning at all.
I can buy "It is too cumbersome to require everybody to reinvent and
script the cascading logic, and the core side should help by giving
a standard interface that is flexible enough to suit people's need",
though.
And I have to say that a sequential execution that always
short-circuits at the first failure is below that threshold.
One reason I care about allowing the users to specify "do not
shortcut" is that I anticipate that people would want to have a
logging of the result at the end of the chain.
prev parent reply other threads:[~2016-04-26 21:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 23:51 RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/* Ævar Arnfjörð Bjarmason
2016-04-25 17:45 ` Junio C Hamano
2016-04-26 10:58 ` Ævar Arnfjörð Bjarmason
2016-04-26 13:40 ` Marc Branchaud
2016-04-26 16:09 ` Ævar Arnfjörð Bjarmason
2016-04-26 17:52 ` Christian Couder
2016-04-26 21:09 ` Marc Branchaud
2016-04-26 21:52 ` Junio C Hamano [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq60v4don1.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).