Re: Checking in files with trailing white space

[Eli Zaretskii <eliz@gnu.org>]

> Cc: acm@muc.de, larsi@gnus.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 13 Dec 2016 10:33:07 -0800
> 
> > what about data files that cannot be easily produced from text on
> > any garden-variety system?
> 
> An Elisp program can easily produce data files in any format, so this 
> should not be a problem in practice.

Producing arbitrary output from a text description might not be easy.
Unless you are willing to accept ASCII-ized binary files in the form
of hex dump or something.  That might make some files harder to read,
not easier, though.  IOW, Git will be happier, but we the humans might
not be.

> > We don't want to make the job of adding tests any harder than it 
> > already is. 
> 
> We can tolerate low-quality tests, I suppose. But it's better if tests 
> are readable and work well with standard tools like "git diff". So we 
> should encourage replacing binary data with text in the repository, as 
> this will make the tests more maintainable.

I'm okay with encouraging that, I just don't think we should require
it.

> This is not merely a practical point; it's also a philosophical one. The 
> GPL distinguishes source code from object code. Typically, binary data 
> files are "object code" in the GPL sense, in that they are not the 
> preferred form of a test case for software-development tools like Git. 
> Whenever we distribute object code, the GPL implies that we should also 
> distribute the corresponding source code that is easy for Git etc. to 
> work with. This source code belongs in the Git repository, and the 
> corresponding object code need not and should not be in the Git repository.

I'm not sure this is relevant here.  E.g., we distribute Emacs sources
as a compressed archive, not as a set of plain-text files.  So stuff
like entry.strange.gz is not an issue in this respect, I think.