Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 14, 2016, 18:01 UTC
Message-ID: <xmqqoa1ix7nq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <0c39be16-76f8-0800-41a2-b7b1dccdd652@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

> *My* idea of --no-index was for it to behave as similar to the
> --index-version as possible, regarding formatting etc., and to be a good
> substitute for ordinary diff. The proposed patch achieves exactly that -

Does it?  It looks to me that it does a lot more.

> why should a *file* argument (which is not a pathspec in --no-index
> mode) not be treated in the same way in which every other command treats
> a file argument? The patch un-breaks the most natural expectation.

I think a filename given as a command line argument, e.g. <(cmd), is now treated more sensibly with [2/2]. Something that is not a directory to be descended into and is not a regular file needs to be made into a form that we can use as a blob, and reading it into an in-core buffer is a workable way to do so.

However, when taken together with [1/2], doesn't the proposed patch "achieves" a lot more than "exactly that", namely, by not treating symbolic links discovered during traversals of directories given from the command line as such and dereferencing?