Junio C Hamano venit, vidit, dixit 14.11.2016 19:01: > Michael J Gruber <g...@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.
Yes, I didn't mean to say that it achieves only that - it achieves that one goal exactly, and 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. Yes. > 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? It's not clear to me what you are saying here - 1/2 makes git diff follow symbolic links, yes, just like ordinary diff. If I 'diff' two dirs that contain symbolic links with the same name pointing to different files I get a diff between the contents, not between the filenames. I like the proposed change a lot, maybe that didn't come across clearly. I think it makes things more "predictable" in the sense that it meets typical expectations. Michael
