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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 14, 2016, 03:14 UTC
Message-ID: <xmqqwpg6ycpn.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1611121106110.3746@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 20 quoted lines

> On Fri, 11 Nov 2016, Jacob Keller wrote:
>
>> On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:
>> >
>> >> No tests or documentation updates yet, and I'm not sure whether
>> >> --follow-symlinks in other modes than --no-index should be supported, ignored
>> >> (as it is now) or cause an error, but I'm leaning towards the third option.
>> >
>> > My knee-jerk reaction is:
>> >
>> >  * The --no-index mode should default to your --follow-symlinks
>> >    behaviour, without any option to turn it on or off.
>> >
>> 
>> I agree. We shouldn't have to specify this for no-index.
>
> Ummm. *My* idea of --no-index was for it to behave as similar to the
> --index version as possible. For example when comparing directories
> containing symlinks. You seem intent on breaking this scenario.

Perhaps a viable compromise between the two is to only always dereference at the top-level (i.e. the trees to be compared) under "--no-index" mode and not changing anything else?

The original use case by Dennis is not even about doing a recursive two-directories-in-a-filesystem comparison and encountering a symbolic link (it was to compare two BLOBs, which happen to be output from two commands).