From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_WEB,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id E3B331F9FC for ; Mon, 22 Mar 2021 05:48:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229728AbhCVFr5 (ORCPT ); Mon, 22 Mar 2021 01:47:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbhCVFrZ (ORCPT ); Mon, 22 Mar 2021 01:47:25 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4529C061574 for ; Sun, 21 Mar 2021 22:47:24 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id lr1-20020a17090b4b81b02900ea0a3f38c1so10556209pjb.0 for ; Sun, 21 Mar 2021 22:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hpT5SccL+IMXRptCgWM3YPnfvnZ6aiVHLdbFK5R9pyg=; b=IwXlDnh7vGhsOxuGSflLBdMUL9BL8bVYnnWk0I1tAYbxOkmGFBJ9TWGHWfsGx2jZbo THFi+QBItcqeSynGTKMlMVfUMSy2nUD2bzchZD2uKootUsK08/p18HWPwds0PcAcvZJV dkCXBhrf1JvYLmZTcY95UkrKnOzEHQu/s6W84fS+V4Vx08KjIVQM1laHuEd75gwaFWXZ rSD3ALfHBSb2Bq5gdbX857w5iQ0lODmoqmx7EmLHfBuwS0dseSfPiR/uf3pBNd3dZKuv CIekx4kamRVnszjw9JAGmWU80rOUprIcD32X7NBl5fs8boy0OicSBT2PrqMHY1LH54hy Gnng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hpT5SccL+IMXRptCgWM3YPnfvnZ6aiVHLdbFK5R9pyg=; b=q1PSQ1IbKaiPVrOoVXZOqyen33DyUm7soU6JwFG7f1EbvPIWqtKyLgkmSoSfoz84H/ AwTN4w7/cDWLyRxGjYMRNBaXh2vwLWGx9mYeQcENUzidFT5UIwud5TJDUqZssvYkEOe4 iiU07u0wLw5CMLsKE1laEgWQ9J6ed9jjeZijTGst9hzkoqSEhY4QDxJhO/FXm3vOS672 eq5whpdQQ4G0fhJ0w1XzQrSrN+kn7Ty7sQenk8nN351fjEzq6C5NGNWpJt+w0S1XQ7vt PWRN7sHUiARDhbPgtNA0DsiVOZThjyBTBdAP8pvNtEEhguWR2byjTcHZ8V3mw/f+smIY bu/A== X-Gm-Message-State: AOAM531rJa10WkmVfqRu3NW++TJB5HZ2dJrBM61B9SOm7Lu35pws5uQl 9N9XiaIRGtXV3+ICROwHngL/oJ69DtaXFDBE X-Google-Smtp-Source: ABdhPJww537gP11dy1HUb/1ykXdSyE7r3FYqDeUOO/ZtP2HD2zXwpzZjZAoIGex38R3Gs6D+9ay36g== X-Received: by 2002:a17:90a:7847:: with SMTP id y7mr11811185pjl.65.1616392044247; Sun, 21 Mar 2021 22:47:24 -0700 (PDT) Received: from [192.168.43.80] (subs03-180-214-233-16.three.co.id. [180.214.233.16]) by smtp.gmail.com with ESMTPSA id b24sm11180225pgj.58.2021.03.21.22.47.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Mar 2021 22:47:23 -0700 (PDT) Subject: Re: Blob hash of binary files in patches generated by git format patch show in full form instead of short form To: Junio C Hamano Cc: git@vger.kernel.org References: <499c9922-eb42-c2a8-b4b4-8e5197ea0fc6@gmail.com> From: Bagas Sanjaya Message-ID: <56cde808-95c3-2e22-2dab-880061d51473@gmail.com> Date: Mon, 22 Mar 2021 12:47:21 +0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On 22/03/21 00.31, Junio C Hamano wrote: > Bagas Sanjaya writes: > >> What's different between what you expected and what actually happened? >> >> Blob hash for binary files are shown in full form, as opposed to blob hash >> for text files. > > This is working as intended, designed and implemented. > > The textual patch is meant to be applicable on target text that may > even have been slightly modified from the original from which the > patch was taken, and the abbreviated object name on the "index" line > is there mostly for human's sanity check and as a visual aid. > Ordinarily it is not used to actually find the matching blob object > (and it is not an error if there is no matching blob object in the > repository that a patch application is attempted in). > > But the binary patch is designed to be applicable only to an exact > copy of the original and nowhere else. The object name is given in > full, instead of using abbreviated form, to ensure that we do not > try to apply a binary patch to an object whose name is "similar". > > Thanks. > Hmm... but I don't see that in the documentation for git format-patch. Maybe I need to send doc update. -- An old man doll... just what I always wanted! - Clara