From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 5B9541F452 for ; Wed, 5 Apr 2023 08:32:10 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=jarry.cc header.i=@jarry.cc header.a=rsa-sha256 header.s=gm1 header.b=VQANCJAc; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237413AbjDEIbh (ORCPT ); Wed, 5 Apr 2023 04:31:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230163AbjDEIbg (ORCPT ); Wed, 5 Apr 2023 04:31:36 -0400 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 836D01BDD for ; Wed, 5 Apr 2023 01:31:35 -0700 (PDT) Received: (Authenticated sender: robin@jarry.cc) by mail.gandi.net (Postfix) with ESMTPSA id 1DFA61BF20C; Wed, 5 Apr 2023 08:31:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jarry.cc; s=gm1; t=1680683493; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6YVL9l3QCnYH5iTKwsPNkbz6I458S18rFwk4cPq1lf4=; b=VQANCJAcLQ3Kn/9xf+m86dzeeOZzRzQILP9YXg5Bqvv+Siu8xOI00SUUMf5IS9Wl+w7xIG Sdcyhw6OLO8ldjI5MFiVeN/oF7FG9aewRfrt974Tj10zJuGa5Xhy+oD5RbQ1yAF9LmXQsp OzNvwHlDBediLlisNriwoaLDXjeCYUTCH/9IHiWbAUQKsar7/fTYdx6UdLlsMXZy25IT+g 5agkKeNp99x9y8RjGq5Cg78GFKzB0Xv3cm+m78ju6g71yioK54+KwTlit1k9/RhqGGaEJN Z3A6iHpQRfAg9r3BipxLEfvLfL3yWo/i6o8og921kBqAa69YI7HEk7gt54OFsQ== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 05 Apr 2023 10:31:28 +0200 Message-Id: To: "Junio C Hamano" Cc: , , "Tim Culverhouse" , "Nicolas Dichtel" , "Bagas Sanjaya" , "Eric Sunshine" Subject: Re: [PATCH RESEND] hooks: add sendemail-validate-series From: "Robin Jarry" X-Mailer: aerc/0.14.0-147-gac3061ba16e0 References: <20230402185635.302653-1-robin@jarry.cc> <66099367-4ea0-7d2a-a089-7a88e27f695e@dunelm.org.uk> In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano, Apr 04, 2023 at 22:14: > Feeding the filenames as the command line arguments would have been > much simpler X-<, Just a thought. Instead of adding another hook, wouldn't it be better to add an option --validate-series (git config sendemail.validateSeries) that would change the behaviour of the sendemail-validate hook? Calling it with all patch files as command line arguments only once instead of once per file. I know I was concerned with the max size of the command line args but is there really a chance that we hit that maximum? On my system, it is 2097152 bytes. Even with a 1000 patches series with 1000 bytes filenames, we wouldn't hit the limit. This way, we support any crap filename that the user may send and we don't add a new hook which basically does the same thing than the existing one. Thoughts?