Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2015, 19:00 UTC
Message-ID: <xmqq4mhoatna.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <D68CC6D0-3FD5-4423-A9E2-905DF18E893F@web.de>

Torsten Bögershausen <tboegi@web.de> writes:

Show 5 quoted lines

> 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

Two unrelated (to the issues raised in other review responses) issues in the UI:

 - While I can see how the new feature would be useful, I am not
   convinced that it is a good idea to add it to ls-files.  Does the
   option work well with other existing options like -s, -t, etc?
   Does it make sense to combine it with other options like -m, -d,
   etc?  I have this suspicion that "check-attr", "check-ignore",
   etc.  may give a better model that fits this feature better,
   i.e. "git check-eol".

 - When you have an operation that works on contents in the working
   tree, the established command line convention to alter the
   operation to work on contents in the index is with "--cached",
   and the operation by default would work on the contents in the
   working tee without "--worktree".  See gitcli(7).

   If I were doing this as part of "ls-files", I would add a new
   "--get-eol" option that inspects the working tree, and make
   "--get-eol --cached" do the same for the contents in the index,
   for consistency.  If I were doing "git check-eol", then the
   default mode of the operation would read from the working tree,
   and "git check-eol --cached" would read from the index.

   If the operation can work on both the contents in the index and
   in the working tree at the same time, we use "--index" instead of
   "--cached", but I do not think it applies here (only a small
   number of commands work on both to begin with, e.g. "apply").