Torsten Bögershausen <tboegi@xxxxxx> writes:
> Make it possible to show the line endings of files.
> Files which are staged and/or files in the working tree:
>
> git ls-files --eol-staged
> git ls-files --eol-worktree
>
> Both will show an output like this:
>
> empty empty_file
> bin binary_file_or_with_cr_handled_as_binary
> txt-crlf text_file_with_crlf
> txt-mix text_file_with_crlf_and_lf
> txt-lf text_file_with_lf
> txt text_file_with_no_eol_at_all
This _may_ be readable by who implemented it, but I cannot tell what
you are trying to say above; "like this" does not help me at all
deciphering.
Do I get the above after doing this?
$ >empty
$ >empty2
$ git ls-files --eol-worktree
empty empty_file
empty2 empty_file
or do you mean this?
$ >empty_file
$ >empty_file2
$ git ls-files --eol-worktree
empty empty_file empty_file2
or do you produce output one path at a time?
$ >empty_file
$ >empty_file2
$ git ls-files --eol-worktree
empty empty_file
empty empty_file2
> txt text_file_with_no_eol_at_all
Does it help to have this category at all? This gives the user an
indication that this file consists on a single incomplete line and
differentiates it from a file with the same single line with LF or
CR/LF line ending. What happens when I prepend to these three files
another copy of the same line with LF or CR/LF line ending? You get
6 variations:
1. line LF line
2. line LF line LF
3. line LF line CRLF
4. line CRLF line
5. line CRLF line LF
6. line CRLF line CRLF
If you say 1 and 2 are with LF, 4 and 6 are with CRLF, eveyrything
else is mixed, then you are losing the distinction between 1 and 2
(and 4 and 6) that you made when the files were a single liner (with
or without the incomplete line ending). Is that desirable?
I wonder if it would be easier for the scripts that process the
output from this command to handle if the report said what
combination of _three_ possible line-ending is used. i.e. does the
file contain a line that ends with LF? does the file contain a line
that ends with CRLF? does the file contain a line with missing EOL?
> Implementation details:
> Make struct text_stat, is_binary() and gather_stats() from convert.c
> public, add a new function get_convert_stats_ascii() and use it
> in and use them in ls-files.
> git ls-files --eol-staged will give a line like this:
>
> Signed-off-by: Torsten Bögershausen <tboegi@xxxxxx>
> ---
This is even worse than the "like this" above ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html