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.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, 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 EEC07202A0 for ; Tue, 24 Oct 2017 01:54:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751295AbdJXByM (ORCPT ); Mon, 23 Oct 2017 21:54:12 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:57867 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751226AbdJXByM (ORCPT ); Mon, 23 Oct 2017 21:54:12 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 795C396554; Mon, 23 Oct 2017 21:54:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=VCR/pADgKJYMHWaQxK0qWYJhpsw=; b=NS6+fm 676OJQu5jibhI/EJQ8AE8LAEyA44BCNb0999CxU/fhwhpQNqVl3yeBtvpAQRgl40 Sipa8qiXx8fRHC8DLBIQXnc0vBEcmXMa9GxD2lFRmGOBFT2HRCn3Oi8xDVP9pwMZ MwX4ppSme3YcJh358vYo+tAj8pO2oOoO60USI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=yORbt4+c6BmGQyE6Oy2BLIBHM1/gqD5t F2HH0OdkX6hHRIQXxkVkYF8lx9i4NdAfiaOX/ZvAKzGzns0VQbNgvi4zbVPBLTGw 0vIO+wPlhTNAzVpvGoZ2e/KPGRXJFlfDHSp2cy2NmDZAKeX4xi99WYl5yNIhIWWu +rjZV4IhRj8= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 70E1896553; Mon, 23 Oct 2017 21:54:11 -0400 (EDT) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id D697896552; Mon, 23 Oct 2017 21:54:10 -0400 (EDT) From: Junio C Hamano To: Stefan Beller Cc: Jonathan Nieder , Brandon Williams , "git\@vger.kernel.org" , Bryan Turner , Jeff Hostetler , Jonathan Tan , Jeff King , William Yan Subject: Re: [PATCH 1/5] connect: split git:// setup into a separate function References: <20170926235627.79606-1-bmwill@google.com> <20171003201507.3589-1-bmwill@google.com> <20171003201507.3589-11-bmwill@google.com> <20171003214206.GY19555@aiede.mtv.corp.google.com> <20171016171812.GA4487@google.com> <20171023212740.qodxzsq5w7rn2r6y@aiede.mtv.corp.google.com> <20171023212916.4aarismli6io4ro6@aiede.mtv.corp.google.com> Date: Tue, 24 Oct 2017 10:54:09 +0900 In-Reply-To: (Stefan Beller's message of "Mon, 23 Oct 2017 15:16:13 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 3AB74FF0-B85E-11E7-AB56-8EF31968708C-77302942!pb-smtp1.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Stefan Beller writes: > I think once this option is given, all we have to do is pay attention to > this option in diff.c#moved_entry_cmp/next_byte, which is best built > on top of Peffs recent fixes origin/jk/diff-color-moved-fix. > Would that be of interest for people? Two things and a half. * I was hoping that the next_byte() and string_hash() thing, once they are cleaned up, will eventually be shared with the xdiff/ code at the lower layer, which needs to do pretty much the same in order to implement various whitespace ignoring options. I am not sure how well the approach taken by the WIP patch meshes with the needs of the lower layer. * I agree that -w that applies only one or the other and not both may sometimes produce a better/readable result, but the more important part is how the user can tell when to exercise the option. Would it be realistic to expect them to try -w in different combinations and see which looks the best? What if we have a patch that touch two files, one looks better with -w only for coloring moved and the other looks better with -w for both? * As moved-lines display is mostly a presentation thing, I wonder if it makes sense to always match loosely wrt whitespace differences. It is tempting because if it is true, we do not have to worry about the second issue above. Thanks.