From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by sourceware.org (Postfix) with ESMTPS id 8CDE73851C25 for ; Wed, 30 Dec 2020 21:34:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8CDE73851C25 Received: by mail-qk1-x72a.google.com with SMTP id 22so15009368qkf.9 for ; Wed, 30 Dec 2020 13:34:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qzvLPpxx7Czs6e4BxBZrc9j4IU72sHhigehL3xHiJwk=; b=m+hSNk3L9WqWc4EleIyBeNsQghNk1gLHVvKgibGwtdgUH2ZgCrGnPYfdGFkXKh9akL OOjCj4two964P1I/mFCIw3gOA3tYb+KCWbmdb59rrjia78wVIOtfw7OKRMNYntQhTX8C 7wHujxmXUKAPfBB0qDeHxH9wDikaMu9ZTXinPbLLIZEu9I3T2ctvTtBrxWY+Ra6YqguJ q05o3Yw20eOx0CpHAdz8jJti+A+ypdn9t+hSOWQdlgFUzOSqn54jDZ3dhrIlmFPldseK vofL90YdByomGpD/5c4XDwb3GYnc7L/hfqXQICsXzMZnYIs2cZ/U2tr7gRyJ1x1+H2wP 0GnQ== X-Gm-Message-State: AOAM533SPq2Lb4mQJ+AFbjJOeE750TPCktXTFZNL9xeFAhSBZhGSGSWp W0cMAcfZYX1N16B3Jweafghe+cs9uQM= X-Google-Smtp-Source: ABdhPJyghGYugxV7MYpbrSkzzrS1/JH4dyUzIrB4LHtPZr4XTHtM28XoSy6+OiwIZ+dSR+mN/XZBgw== X-Received: by 2002:a05:620a:12f2:: with SMTP id f18mr53004354qkl.483.1609364099005; Wed, 30 Dec 2020 13:34:59 -0800 (PST) Received: from [192.168.0.41] (75-166-96-128.hlrn.qwest.net. [75.166.96.128]) by smtp.gmail.com with ESMTPSA id d72sm28104521qkg.34.2020.12.30.13.34.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Dec 2020 13:34:58 -0800 (PST) From: Martin Sebor Subject: Re: More consistency for Git log messages? To: Jonathan Wakely , Gerald Pfeifer Cc: gcc@gcc.gnu.org References: <43eb3d64-2d5d-cbc9-3e3e-e06eedc2704b@pfeifer.com> Message-ID: <58169830-3f6c-eea8-dd6a-734917882271@gmail.com> Date: Wed, 30 Dec 2020 14:34:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 21:35:00 -0000 On 12/29/20 1:49 AM, Jonathan Wakely via Gcc wrote: > On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer, wrote: > >> Having spent a bit more time with GCC sources (as opposed to wwwdocs) >> recently and looking for prior art to guide me, I noticed there's a >> lot of options to specific the ChangeLog file(s) to use. >> >> And correspondingly a lot of inconsistency. >> >> Right now we seem to allow for >> >> 1. gcc/cp/ChangeLog >> 2. gcc/cp/ChangeLog: >> 3. gcc/cp >> 4. gcc/cp: >> 5. gcc/cp/ >> >> and probably more. >> > > We also allow not specifying the directory at all, if it can be deduced > from the changed files. That's a nice feature I didn't even know about! >> Can we streamline this a bit and converge on one of the forms 3-5? >> >> Personally I'd suggest 3 (the shortest) or 5 (the directory), but whatever >> ... as long as things become more consistent, which is easier on newbies >> and reading logs (or automatically processing them later on). >> > > We already process them automatically. > > It's worth noting that some people generate then automatically too, and the > mklog.py hook uses form 2 IIRC. I believe you're right. I use the script to generate a template for my first patch. For subsequent revisions I copy the template from the first one and edit it by hand (and often mess things up, making the commit hook complain). I rarely read ChangeLogs so I'm not bothered by inconsistencies in it but I can relate to those who do and are. I'm not against increasing the consistency of the format just as long as it doesn't make the commit procedure more onerous. Changing the commit hook to massage the ChangeLog lines (and any other minutiae) into a preferred format would do that. Martin