Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Nov 14, 2016, 20:23 UTC
- Message-ID
- <a3db4c55-550c-f2e8-83b8-46c2be86f7da@drmicha.warpmail.net>
- In-Reply-To
- <xmqqoa1ix7nq.fsf@gitster.mtv.corp.google.com>
Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
Show 7 quoted lines
> 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.
Yes, I didn't mean to say that it achieves only that - it achieves that one goal exactly, and more.
Show 9 quoted lines
>> 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