From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Checking in files with trailing white space Date: Wed, 14 Dec 2016 21:26:53 +0200 Message-ID: <83inqm9urm.fsf@gnu.org> References: <20161211133110.GB14084@acm.fritz.box> <20161212221642.GA4361@acm.fritz.box> <83wpf4bj26.fsf@gnu.org> <366009d8-72f4-2f85-103c-214a5e111e77@cs.ucla.edu> <83oa0fbyx6.fsf@gnu.org> <8360mnbqnz.fsf@gnu.org> <053170b4-0258-bf23-c20b-236be50c984b@cs.ucla.edu> <83zijz9og4.fsf@gnu.org> <83wpf2a5mf.fsf@gnu.org> <24b79e5f-4028-b3ad-5649-f5b270070770@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1481743698 12840 195.159.176.226 (14 Dec 2016 19:28:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Dec 2016 19:28:18 +0000 (UTC) Cc: acm@muc.de, larsi@gnus.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 14 20:28:11 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cHFDm-0002SS-2m for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2016 20:28:10 +0100 Original-Received: from localhost ([::1]:49764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHFDq-0005hF-Dc for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2016 14:28:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHFDi-0005X2-IE for emacs-devel@gnu.org; Wed, 14 Dec 2016 14:28:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHFDe-0006SX-PC for emacs-devel@gnu.org; Wed, 14 Dec 2016 14:28:06 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHFDe-0006ST-M0; Wed, 14 Dec 2016 14:28:02 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4718 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cHFDb-0001pJ-Pe; Wed, 14 Dec 2016 14:28:02 -0500 In-reply-to: <24b79e5f-4028-b3ad-5649-f5b270070770@cs.ucla.edu> (message from Paul Eggert on Wed, 14 Dec 2016 10:15:55 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210465 Archived-At: > From: Paul Eggert > Date: Wed, 14 Dec 2016 10:15:55 -0800 > Cc: acm@muc.de, larsi@gnus.org, emacs-devel@gnu.org > > I've attached a list of repository-controlled files that are not UTF-8 > text files in the POSIX sense. Of the 433 such files, I count 181 Netpbm > image data, 107 gzipped files (mostly gzipped text), 57 PNG files, 11 > PDF files, and there is a hodgepodge of assorted other formats. A few > files are in the list merely because they lack a trailing newline (a > problem for some tools, and POSIX says such files are not text files). > (For a sense of the scale here, all this is out of 3695 files total in > Emacs master right now.) > > Most of the files in this list are merely awkward and are not a GPL > issue; these include the gzipped text files, the text files that use > non-UTF-8 encodings, and the no-trailing-newline files. And many files > are there because we have put object files into the source repository, > where we really should be generate them as part of the build and limit > the repository to source code; these include the PBM and PNG files (or > at least I hope they do; I haven't checked). There are no licensing issues with any of those, each one was verified at the time, AFAIR. As for generating them from text: feel free to scratch that itch, if you want to. > > Depends on the compression method, I guess. For some of them, we > > cannot rely on the respective tools being available, so if that > > particular kind of compression is needed for some test, having the > > source file might not be good enough. > > We can assume gzip Yes. Gzip was not what I had in mind.