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

From: Torsten Bögershausen <tboegi@web.de>
Date: Oct 19, 2015, 05:23 UTC
Message-ID: <56247E3F.40804@web.de>
In-Reply-To: <xmqq4mhoatna.fsf@gitster.mtv.corp.google.com>

On 18/10/15 21:00, Junio C Hamano wrote:

Show 18 quoted lines

> 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
> 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".
>

(This should answer all comments, thanks everybody @Erics Sunshine: Thanks for the review, dropped you from cc list because web.de can't find an MX record)

I like this idea:

binary text crlf mixed lf

----------------
$ git ls-files --eol-staged -s
  [snip]
  100644 981f810e80008d878d6a5af1331c89dc093c5927 0       txt-lf worktree.c

---------------------
$ rm  Documentation/RelNotes/2.7.0.txt
$ echo "/* */" >>builtin/ls-files.c
$ ls-files -m --eol-worktree
   empty    Documentation/RelNotes/2.7.0.txt
   txt-lf   builtin/ls-files.c
-----------------------
(The empty is a bug, thanks Eric)
------------------------------
$ ./git-ls-files --eol-worktree -t
[snip]
$ H txt-lf   zlib.c
-------------------------
My understanding is that the eol options work togther with the existing option,
as long as it makes sense (but see below)

"git check-attr" will even report attributes for a file, that doesn't even exist. "git ls-files is a command which by default operates on the staged area, unless I mis-understand it.

And that is the main purpose: Tell me how which line endings your staged files have, and I can tell you that you may consider to normalize these files because "git status", "git blame" consider these files as changed.

(From that point of view, "git ls-files --eol" could be the way to report the staged eols. But then users would ask: but why can't you tell me what I have in my worktree ?

"git ls-files --eol-worktree" could be the answer (or "git ls-files -o --eol-worktree" )

I was thinking about adding "git check-eol", but didn't want to introduce just another command, as the syntax and options (-z, -o -x -X) overlap much with ls-files

Is it the common understanding to add a new command is the best solution ?