From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2420DC35666 for ; Sat, 22 Feb 2020 16:56:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C1CAD206E2 for ; Sat, 22 Feb 2020 16:56:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="VB9zZXa3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726766AbgBVQ4P (ORCPT ); Sat, 22 Feb 2020 11:56:15 -0500 Received: from pb-smtp20.pobox.com ([173.228.157.52]:52768 "EHLO pb-smtp20.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726688AbgBVQ4P (ORCPT ); Sat, 22 Feb 2020 11:56:15 -0500 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 7658FB9FB5; Sat, 22 Feb 2020 11:56:13 -0500 (EST) (envelope-from junio@pobox.com) 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=Amy5KNYKryt8ZDHRjVCBXFVj7fw=; b=VB9zZX a3SlNb6gTl/GSjtx24rxrmabh5gxw5NYRq448ek3c3d42YVBV8FexK46xFHBgiD4 brXvfkI6ksEh9y5d1RffoAPIULB4s1W5abhxf6CmPcZYawV096EcBTDBiX5POyAZ IlFqwaQ6h2XW3NPgSSCxv4u8uT7tto+QA5Wx8= 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=Vf9L85/Lf8b9NqSfc6RGpL+FLehOHs0g Nmnzop3lh6Oi7QHzubHFR1sSRSyzcCyK92V/IFZkFgiX3bJWj+GrOA76Rso+FGXi F0ShW6OpMsjD5shtc7FQWkOLmN7quQrYw04Ckw7QS0IT0yAAS8UakhLujBvcFUA0 9BkqMXmO8mg= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 6E4DAB9FB4; Sat, 22 Feb 2020 11:56:13 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.76.80.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 906E0B9FB1; Sat, 22 Feb 2020 11:56:10 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: Konstantin Ryabitsev Cc: git@vger.kernel.org Subject: Re: Getting clean diff data from git-mailinfo References: <20200221171312.xyzsrvebuwiw6pgj@chatter.i7.local> Date: Sat, 22 Feb 2020 08:56:08 -0800 In-Reply-To: (Junio C. Hamano's message of "Sat, 22 Feb 2020 08:47:42 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 3A12F308-5594-11EA-9588-B0405B776F7B-77302942!pb-smtp20.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano writes: > ... then we may have had split (3) into three pieces: > > (3a) material before the pure diff (e.g. diffstat, etc.) > (3b) pure diff > (3c) trailing junk (e.g. base-commit info, e-mail signature, etc.) > ... > So, because there is no such need so far, there is no tool in the > Git toolbox to split (3) into three pieces. > > You're welcome to write one, but the current toolset does not need > it. Writing something that reads (3), discarding lines before the first "diff --git", counting lines that appear on "@@ ... @@" line while copying it to the output, repeating the process when you see something other than "diff --git" (i.e. beginning of the patch for the next path) or "@@ ... @@" (i.e. another hunk in the patch for the current path), and discarding the rest may be trivial. But in practice, people edit their diff [*1*], forgetting the line counts on the "@@ ... @@" lines, and it helps the maintainer to have the whole (3), not only (3b), in a single file to recover from such a broken patch submission. So adding another tool to produce (3b) only is fine, but an attempt to get rid of (3) and to claim that (3b) replaces the need for (3) is highly discouraged. Thanks. [Footnote] *1* Even when people edit without changing the line numbers (imagine a typofix on a '+' line), I saw that "patch" mode of Emacs broke the line count on "@@ ...@@" line of the last hunk when the patch ends with certain patterns.