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

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

Torsten Bögershausen [off-list ref] writes:

quoted

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 ?