From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 952371F404 for ; Sat, 3 Mar 2018 06:19:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751568AbeCCGSG (ORCPT ); Sat, 3 Mar 2018 01:18:06 -0500 Received: from cloud.peff.net ([104.130.231.41]:45390 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750924AbeCCGSG (ORCPT ); Sat, 3 Mar 2018 01:18:06 -0500 Received: (qmail 9694 invoked by uid 109); 3 Mar 2018 06:18:06 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with SMTP; Sat, 03 Mar 2018 06:18:06 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 3612 invoked by uid 111); 3 Mar 2018 06:18:54 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.94) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) SMTP; Sat, 03 Mar 2018 01:18:54 -0500 Authentication-Results: peff.net; auth=none Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Sat, 03 Mar 2018 01:18:02 -0500 Date: Sat, 3 Mar 2018 01:18:02 -0500 From: Jeff King To: Junio C Hamano Cc: Sam Kuper , git@vger.kernel.org Subject: Re: Bug report: "Use of uninitialized value $_ in print" Message-ID: <20180303061802.GJ27689@sigill.intra.peff.net> References: <20180302104232.GA11074@sigill.intra.peff.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Mar 02, 2018 at 01:53:32PM -0800, Junio C Hamano wrote: > Sam Kuper writes: > > > 1. It would yield, IIUC, less flexibility to create new kinds of view > > based on a consistent, standardised underlying model. > > > > 2. It is harder to read, for some types of input (e.g. prose) than the > > view generated by the existing word-diff algorithm. > > The loss of line-end by the lossy "word-diff" output does not matter > if you never split hunks, but to be able to split a hunk at an > in-between context line (which you can already do) and new features > like per-line selection that are emerging, keeping 1:1 line > correspondence between what is shown and what is applied is a must. > > Unless you are volunteering to design (notice that I am not saying > "implement") both diff generation/coloration side _and_ patch > application side, that is. In which case, you may be able to come > up with a magic ;-) IIRC, we do the word-diff by first finding the individual hunks with a normal line diff, and then doing a word diff inside those hunks. So one easy option would be to add a --color-words option that gets passed along to the underlying display diff and just disables hunk splitting. I think we'd also need to start parsing the DISPLAY hunks more carefully to make sure we re-sync at hunk boundaries. -Peff