Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> On Mon, 14 Nov 2016, Junio C Hamano wrote:
>>
>>> I _think_ the no-index mode was primarily for those who want to use
>>> our diff as a replacement for GNU and other diffs, and from that
>>> point of view, I'd favour not doing the "compar
Johannes Schindelin writes:
> On Mon, 14 Nov 2016, Junio C Hamano wrote:
>
>> I _think_ the no-index mode was primarily for those who want to use
>> our diff as a replacement for GNU and other diffs, and from that
>> point of view, I'd favour not doing the "comparing symbolic link?
>> We'll show
Hi Junio,
On Mon, 14 Nov 2016, Junio C Hamano wrote:
> I _think_ the no-index mode was primarily for those who want to use
> our diff as a replacement for GNU and other diffs, and from that
> point of view, I'd favour not doing the "comparing symbolic link?
> We'll show the difference between the
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
>> Michael J Gruber 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 pr
Junio C Hamano venit, vidit, dixit 14.11.2016 19:01:
> Michael J Gruber 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
Michael J Gruber 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
Hi Michael,
On Mon, 14 Nov 2016, Michael J Gruber wrote:
> 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?
We are talking about `<(command)` here, which is most distinctly not a
file
Johannes Schindelin venit, vidit, dixit 12.11.2016 11:08:
> Hi,
>
> On Fri, 11 Nov 2016, Jacob Keller wrote:
>
>> On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote:
>>> Dennis Kaarsemaker writes:
>>>
No tests or documentation updates yet, and I'm not sure whether
--follow-symlinks
Johannes Schindelin writes:
> On Fri, 11 Nov 2016, Jacob Keller wrote:
>
>> On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote:
>> > Dennis Kaarsemaker writes:
>> >
>> >> No tests or documentation updates yet, and I'm not sure whether
>> >> --follow-symlinks in other modes than --no-index sh
Hi,
On Fri, 11 Nov 2016, Jacob Keller wrote:
> On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote:
> > Dennis Kaarsemaker 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
On Sat, Nov 12, 2016 at 07:11:34AM +0100, Dennis Kaarsemaker wrote:
> > * If normal "diff" that follows symlinks by default has an option
> >to disable it, then it is OK to also add --no-follow-symlinks
> >that is only valid in the --no-index mode, so that we can mimick
> >it better (
On Fri, 2016-11-11 at 13:27 -0800, Junio C Hamano wrote:
> Dennis Kaarsemaker 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
On Fri, Nov 11, 2016 at 12:19 PM, Dennis Kaarsemaker
wrote:
> Today on #git, a user asked why git diff <(command1) <(command2) gave only
> some
> gibberish about pipes as output. The answer is fairly simple: git diff gets as
> arguments /dev/fd/62 and /dev/fd/63, which are symlinks. So git simply
On Fri, Nov 11, 2016 at 1:27 PM, Junio C Hamano wrote:
> Dennis Kaarsemaker 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 th
Dennis Kaarsemaker 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
Today on #git, a user asked why git diff <(command1) <(command2) gave only some
gibberish about pipes as output. The answer is fairly simple: git diff gets as
arguments /dev/fd/62 and /dev/fd/63, which are symlinks. So git simply
readlink()s them and gets pipe:[123456] as destination of that link w
16 matches
Mail list logo
