From: Junio C Hamano <email@example.com> To: Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> Cc: Git <email@example.com> Subject: Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/* Date: Tue, 26 Apr 2016 14:52:02 -0700 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=H4wacPhHjFbQ@mail.gmail.com> (=?utf-8?B?IsOGdmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Tue, 26 Apr 2016 12:58:04 +0200") Ævar Arnfjörð Bjarmason <email@example.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 index Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-22 23:51 Æ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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git