Re: [PATCH] config: Introduce --patience config variable

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Tue, Mar 06, 2012 at 06:57:42PM -0800, Junio C Hamano wrote:
>
>> > The idea of turning on patience diff via config makes sense to me, and
>> > it is not a problem for plumbing tools to have patience diff on, since
>> > patience diffs are syntactically identical to non-patience diffs.
>> 
>> Even though I do not strongly object to the general conclusion, I
>> have to point out that the last line above is a dangerous thought.
>>
>> If you change the default diff algorithm, you will invalidate long
>> term caches that computed their keys based on the shape of patches
>> produced in the past.
>
> I see your point, though I don't think I'd use the word "dangerous" to
> describe the invalidation of a cache.

I probably was not writing clearly enough to avoid getting misread.
The "dangerous" does not refer to "invalidation of a cache".  What I
meant was that "The output is syntactically identical, so it is OK"
is a dangerous way to think when assessing the risk of regression,
because applying to a given preimage and producing the same
postimage is not the *only* way the output is used.

I think the executive summary is that we are in agreement; your
analysis of potential regression coming from differences of the
shape of the patch output (not applicability to a given preimage to
produce the same postimage) seems to match what I said in the
previous message.

Especially in the kup case, it is a minority tool used by people who
knows or can be easily taught in a tightly controlled environment,
and it is fine as long as the users have a way to make sure two
diffs run on both ends of the communication produce the same result
(in an earlier discussion on k.org users list where kup was first
discussed, the limitation of users having to use the same version as
k.org has was noted and the users are already aware of it).