From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id 87E4D3858D38; Fri, 7 Aug 2020 15:12:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 87E4D3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6725D11708C; Fri, 7 Aug 2020 11:12:04 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pK5yKtpCUFQC; Fri, 7 Aug 2020 11:12:04 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 36839117024; Fri, 7 Aug 2020 11:12:04 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 95B1E82C47; Fri, 7 Aug 2020 08:12:02 -0700 (PDT) Date: Fri, 7 Aug 2020 08:12:02 -0700 From: Joel Brobecker To: Simon Marchi Cc: Rainer Orth , binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [PATCH] Unify Solaris procfs and largefile handling Message-ID: <20200807151202.GB1740@adacore.com> References: <51f44a63-3062-39e5-14c5-ed08e32f2129@simark.ca> <5aae580e-ab2e-f008-91c6-f3b1c1f757b7@simark.ca> <169bf482-296b-737d-2a48-581d5b1d92bb@simark.ca> <4d3bf991-c0e5-2136-5935-4c4e47aadbf2@simark.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d3bf991-c0e5-2136-5935-4c4e47aadbf2@simark.ca> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 15:12:05 -0000 > > I don't usually include generated files in patch submissions, though: > > they are heavily frowned upon at least over in GCC because they make > > review quite difficult, espcially in a case like this where the > > largefile.m4 change spreads to lots of configure scripts, obscuring the > > change proper. > > > > Does GDB handle things differently here? > > I don't think there's a hard rule. If it makes the patch too big for > sending on the list, then it's fine for sure to not include them. If > you don't want to include them, that's fine with my too, but in either > case it's important to say that you've omitted them on purpose so we > know it's not an oversight (otherwise I'll complain about them missing > :)). Historically, we have generally avoided to include them, and if memory serves me right, we've asked people to exclude them from the diff sent for review, because they tend to be mostly noise. We still knew that the contributor wasn't forgetting to recreate them thanks to the ChangeLog entry mentioning the list of files being regenerated. That being said, since the switch to git, and in particular with the use of git-send-email which is uber handy, it's been easier to forget about the stripping. I don't think anyone's made a comment against small diffs of regenerated files. One thing about having the being sent as part of the review is that people can then verify that the files are regenerated using the correct version of the autotools... -- Joel