From: Torsten Bögershausen Date: Mon, 19 Oct 2015 05:23:11 GMT Subject: Re: [PATCH] Add ls-files --eol-staged, --eol-worktree Message-ID: <56247E3F.40804@web.de> In-Reply-To: On 18/10/15 21:00, Junio C Hamano wrote: > Torsten Bögershausen 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 ?