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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
> 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.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]