On Fri, Dec 9, 2016 at 2:36 PM, Junio C Hamano <gits...@pobox.com> wrote: > > I doubt that this is the best place to call this hook, because the > called hook does not have access to information that may help it > make a better decision.
As the commit message may elude, I chose this place as it would be sufficient for checking for ChangeIds, missing signoffs, or even rudimentary check for coding style and commit message line length. > > For example, because the hook gets one patchfile at a time, it does > not have the entire picture (e.g. "are you sure you want 01/05, > 02/05, 04/05 and 05/05 without 03/05?"). For another example, the > hook does not have access to the decision git-send-email makes on > various "parameters", which are computed based on the contents of > the patchfiles and command line arguments at this point in the code. > (e.g. @to, @cc, etc. are computed much later, so you cannot say "do > not send anythnng outside corp by mistake" with this mechanism). > So you are suggesting to * have the check later in the game (e.g. just after asking "Send this email? ([y]es|[n]o|[q]uit|[a]ll): " as then other information such as additional @to @cc are available. * the hook should not just be called one file at a time, but rather we would give all file names via e.g. stdin. With the current code structure this contradicts the first point. I wonder if we want to have multiple hooks for these different things of either looking at the big picture or looking at each in detail. For me currently I am only interested in the small picture thing. Stefan
