From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add ls-files --eol-staged, --eol-worktree
Date: Sun, 18 Oct 2015 10:35:23 -0700 [thread overview]
Message-ID: <xmqqpp0caxlw.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <D68CC6D0-3FD5-4423-A9E2-905DF18E893F@web.de> ("Torsten Bögershausen"'s message of "Sat, 17 Oct 2015 22:18:06 +0200")
Torsten Bögershausen <tboegi@web.de> 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@web.de>
> ---
This is even worse than the "like this" above ;-)
next prev parent reply other threads:[~2015-10-18 17:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-17 20:18 [PATCH] Add ls-files --eol-staged, --eol-worktree Torsten Bögershausen
2015-10-18 1:10 ` Eric Sunshine
2015-10-18 10:03 ` Philip Oakley
2015-10-18 17:35 ` Junio C Hamano [this message]
2015-10-18 18:32 ` Junio C Hamano
2015-10-18 19:00 ` Junio C Hamano
2015-10-19 5:23 ` Torsten Bögershausen
2015-10-19 6:32 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqpp0caxlw.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox