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

[Junio C Hamano <gitster@pobox.com>]

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

> I like this idea:
>
> binary
> text
> crlf
> mixed
> lf

If you really like it, it would mean that my attempt to use Socratic
method to enlighten you why the above is not a good idea failed X-<.

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

Does it even make sense to give --eol-worktree in this case?

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

Both "ls-files -o/-i" talk about untracked paths, so that is not a
very useful and valid objection, is it?

> "git ls-files is a command which by default operates on the staged
> area, unless I mis-understand it.

It is even worse than that.  It is true that "ls-files [-s]" is
about "--cached" and there is no equivalent to show the working tree
version.  But "-t", "-d", etc. are not about the state in the index
nor the state in the working tree.  They are about the relationship
between these two states.

What the new operation wants to do, if I understand correctly, is
either check the blob contents in the working tree or in the index,
which is not a good fit with what the rest of "ls-files" does for
exactly that reason.  The inability to mix -s with --eol-worktree
is another natural consequence of this.

> I was thinking about adding "git check-eol", but didn't want to
> introduce just another command,

Between adding a new command that does one thing well and whose user
interaction is coherent with the rest of the system, and adding a
new operation mode to an existing command and makes the user
interaction of that existing command more incoherent by introducing
two variants --foo and --foo-worktree when there is no existing
option that has similar variant pair, I'd say we prefer to see a new
command.

The -z output, and --stdin input are what we would want to have for
the new command, but I do not think we want it to know -o, -x or -X.
You would instead pipe output from ls-files with these options to
the new command run with the --stdin option.