[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACsJy8CEnKxmhRYQqWoMVyLpfDUp7tqdnLxiV47XqaOFFCcUMw@mail.gmail.com>
Date: Fri, 1 Nov 2013 06:52:35 +0700
From: Duy Nguyen <pclouds@...il.com>
To: Junio C Hamano <gitster@...ox.com>
Cc: Johan Herland <johan@...land.net>, Jeff King <peff@...f.net>,
Michael Haggerty <mhagger@...m.mit.edu>,
Josh Triplett <josh@...htriplett.org>,
Git mailing list <git@...r.kernel.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
Greg KH <greg@...ah.com>,
Linux Kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line
On Fri, Nov 1, 2013 at 12:20 AM, Junio C Hamano <gitster@...ox.com> wrote:
> Duy Nguyen <pclouds@...il.com> writes:
>
>> OK how about, if $GIT_DIR/hooks/something is a directory, then the
>> directory must contain a file named "index", listing all the hooks of
>> type "something". All the hooks in "index" will be executed in the
>> listing order.
>
> Hooks that take arbitrary amount of information from the body read
> their standard input. How are your multiple hooks supposed to
> interact?
If each only needs to read a few lines from stdin, they can do so in
order. If two hooks need to read till the end of stdin, they are
incompatible. If we support some sort of hook signature, we could warn
the user when they combine the two. If not, the second's failing
(because stdin is already closed) may show the incompatibility. "git
hook" should support dry-run mode to test out new combinations.
> Hooks that prevent you from doing something stupid signal allow/deny
> with their exit code. Do you fail a commit if any of your pre-commit
> hook fails, or is it OK to commit as long as one of them says so?
> If the former, do all the hooks described in the index still run, or
> does the first failure short-cut the remainder?
One failed hook fails the commit and stops the remaining from
executing. You can skip the hook if you want with --exclude-hooks.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists