On 18/10/15 21:00, Junio C Hamano wrote:
Torsten Bögershausen <tboegi@xxxxxx> 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 ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html