Re: [PATCH v3] ls-files: Add eol diagnostics

From: Torsten Bögershausen <tboegi@web.de>
Date: Nov 23, 2015, 17:05 UTC
Message-ID: <5653474E.6050909@web.de>
In-Reply-To: <56517AD5.6040909@gmail.com>

On 22.11.15 09:20, Sebastian Schuberth wrote:

Show 17 quoted lines

> On 21.11.2015 08:36, Torsten Bögershausen wrote:
> 
>> git ls-files --eol gives an output like this:
>>
>> i/text-no-eol   w/text-no-eol   attr/text=auto t/t5100/empty
> 
> I'm sorry if this has been discussed before, but hav you considered to use a header line and omit the prefixed from the columns instead? Like
> 
> index         working tree     attributes    file
> 
> binary        binary           -text         t/test-binary-2.png
> text-lf       text-lf          eol=lf        t/t5100/rfc2047-info-0007
> text-lf       text-crlf        eol=crlf      doit.bat
> text-crlf-lf  text-crlf-lf                   locale/XX.po
> 
> I believe this would be both easier to read for humans, and easier to parse for scripts that e.g. want to compare line endings in the index and working tree.
>

The problem I see is to make sure that there is always a separator, even when a field empty:

rm zlib.c; git ls-file --eol #will include a line like this: i/text-lf w/ attr/ zlib.c

or, as another example: git ls-files -o --eol i/ w/binary attr/ zlib.o

And if there is no separator, it is harder to make it machine-parsable, if we e.g. extend the attributes to support "*text=autocrlf", or "*.text=autoinput" (But that is another story)

If we replace "/[-a-z]" with "\t", the line has always a separator,
but needs a somewhat wider screen:
        text-lf         text-lf                   zlib.c

>> +		echo huh $1

[] good catch, thanks