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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2015, 06:32 UTC
Message-ID: <xmqqvba39xn5.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <56247E3F.40804@web.de>

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

Show 7 quoted lines

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