Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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?