Re: Can we clarify the purpose of `git diff -s`?

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

 



Junio C Hamano <gitster@xxxxxxxxx> writes:


> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>> So your rationale to reject a perfectly logical behavior that *everyone* agrees
>> with is that it might break a hypothetical patch?
>
> Everyone is an overstatement, as there are only Sergey and you,

Sorry, do you actually expect there is anybody here who disagrees that
--no-patch logical behavior is to disable --patch? I thought you, in
particular, have already agreed it's exactly "perfectly logical
behavior". So there are at least 3 of us who explicitly agreed it is,
and nobody who stated his disagreement. No?

> and as we all saw in public some members stated they will not engage
> in a discussion thread in which you were involved. In addition, at PLC
> I've seen people complain about how quickly a discussion that involves
> you becomes unproductive---they may have better sence of backward
> compatibility concern than you two, but they are staying silent (they
> are wiser than I am).

The above statement with the word "everyone" was not about backward
compatibility, where we obviously expect different opinions from
different people.

As for the sense, maybe there are people out there who do have better
sense indeed, but then maybe some of them keep silence out of agreement?
For what it's worth, @work I do have to maintain CI that is 600-pages
long document and to take care of backward compatibility, so I do have
at least some experience in this field beyond Git, and I do sympathize
the conservatism in this field, and only argue about practical
thresholds.

As for backward compatibility itself, what I see as a problem is that
the criteria of when backward incompatibility is to be considered a
show-stopper, and when not, are unclear and look entirely voluntary from
here. At least I was not able to correctly predict the outcome so far,
that is rather discouraging.

[...]

> I am *not* shutting the door for "--no-patch";

That apparently confirms that you still do consider it "the perfectly
logical behavior".

> I am only saying that it shouldn't be done so hastily.

I won't even try to insist on immediate fix, though I still don't see
why shouldn't we just do it while we are at the issue, and be done with
it.

> Indeed "--silent" or "--squelch" is one of the things that I plan to
> suggest when we were to go with "--no-patch is no longer -s" topic.

While we are at this, may I vote against "--squelch", please? For me
it'd be undiscoverable, as it's the first time I ever hear this word in
such context. Moreover, from the meaning of the word I'd expect it to
silence output unless the size of diff exceeds some limit, that in turn
makes little sense. Or maybe it makes some sense? Hmm. "Show me only
diffs that are more than 10 lines long". It'd be entirely different
option anyway.

Thanks,
-- Sergey Organov



[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]

  Powered by Linux