From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1jZ6l3-00020Y-Qq for mharc-grub-devel@gnu.org; Thu, 14 May 2020 01:50:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZ6l2-00020N-2t for grub-devel@gnu.org; Thu, 14 May 2020 01:50:12 -0400 Received: from mailout03.mx.bawue.net ([193.7.176.64]:49407) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZ6l0-0000h4-IL for grub-devel@gnu.org; Thu, 14 May 2020 01:50:11 -0400 Received: from n-dimensional.de (p5B17584C.dip0.t-ipconnect.de [91.23.88.76]) (Authenticated sender: pdim@bawue.de) by smtp.bawue.net (Postfix) with ESMTPSA id 4A12D22644 for ; Thu, 14 May 2020 07:50:00 +0200 (CEST) Date: Thu, 14 May 2020 07:49:59 +0200 From: Hans Ulrich Niedermann To: grub-devel@gnu.org Subject: Re: [MULTIBOOT2 SPEC PATCH v3 2/4] multiboot2: Use .gitignore files Message-ID: <20200514074959.356f51d4@n-dimensional.de> In-Reply-To: <20200513231103.2794b447@n-dimensional.de> References: <20200508045049.397997-1-hun@n-dimensional.de> <20200508045049.397997-3-hun@n-dimensional.de> <20200513162111.dzvtob4jpsvk2tdu@tomti.i.net-space.pl> <20200513231103.2794b447@n-dimensional.de> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanner: SAV Dynamic Interface 2.6.0, Engine: 3.77.1, SAV: 5.75 (4D93ACB7) on relay01.mx.bawue.net using milter-sssp 0.1.0 X-Virus-Scan: Found to be clean. Received-SPF: pass client-ip=193.7.176.64; envelope-from=hun@n-dimensional.de; helo=mailout03.mx.bawue.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/14 01:50:07 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 05:50:12 -0000 On Wed, 13 May 2020 23:11:03 +0200 Hans Ulrich Niedermann wrote: > On Wed, 13 May 2020 18:21:11 +0200 > Daniel Kiper wrote: > > > On Fri, May 08, 2020 at 06:50:47AM +0200, Hans Ulrich Niedermann > > wrote: > > > Add .gitignore file and remove the obsolete .bzrignore file. > > > > > > The doc/.gitignore file is generated by gnulib-tool so we keep > > > that file in addition to the top-level .gitignore file which > > > covers everything else in the subdirectory tree. > > > > If it is generated by gnulib-tool why do we need to create it? > > The alternatives to adding doc/.gitignore to the version controlled > files are to either > > a) have the top-level .gitignore file ignore "/doc/.gitignore" > > b) have the gnulib-generated doc/.gitignore file just flying around, > neither .gitignored like all other generated files, nor under > version control > > Option a) sounds like the beginning of a road into world of very weird > and unexpected things, and option b) defeats the purpose of having any > .gitignore or .bzrignore etc. files at all. > > I much prefer ignoring a few patterns which gnulib is considering > useful to be ignored at this time by adding doc/.gitignore. Well, now > that I am thinking about this... > > c) Maybe gnulib would recognize when the top-level .gitignore files > does the job gnulib would create the doc/.gitignore file for. > Then we would just have two more patterns in our top-level .gitignore > file, and gnulib would not create a doc/.gitignore file. > > I will have to investigate option c). I would prefer that over my > original option from the patch (adding the doc/.gitignore file as > generated by gnulib). No luck here. I have just examined what gnulib-tool does in the presence of the proper patterns having been added to the top-level .gitignore file with an absent doc/.gitignore file: gnulib-tool creates a new file doc/.gitignore to which it adds its patterns. So option c) is out, option a) and option b) both create unnecessary friction in the day to day use of git, I am therefore still convinced the best way to go is to have a top-level .gitignore with our own stuff, and a doc/.gitignore file with whatever patterns gnulib-tool wants to put in there together with the scripts it puts into doc/. Note that gnulib-tool creates a few more subdirectory .gitignore files in /lib/ and /m4/. We just do not notice those as we .gitignore the whole subdirectory for those two anyway. The only thing from gnulib we are interested in are the scripts generating HTML from doc/multiboot.texi, not m4 macros or C source files. Uli