All of lore.kernel.org
 help / color / mirror / Atom feed
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 ;-)

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.