Re: [PATCH] config: Introduce --patience config variable
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 7, 2012, 17:24 UTC
- Message-ID
- <7vobs8nx31.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120307114714.GA14990@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 15 quoted lines
> 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).