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=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham 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 809DA1F9FC for ; Sun, 21 Mar 2021 17:32:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230289AbhCURbu (ORCPT ); Sun, 21 Mar 2021 13:31:50 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:57400 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230284AbhCURb2 (ORCPT ); Sun, 21 Mar 2021 13:31:28 -0400 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 791A0A8620; Sun, 21 Mar 2021 13:31:27 -0400 (EDT) (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=o4YEsutDd/oaLIW/VRfaDVb0T1A=; b=aZz1/A H94B18zA5vhi0DLp1J1d7Zv7LERDAs6sLxVyxoTR1yWdvRUvgMWH0+ZKV9kWuRxA N1I6OjoAkBci304Wg/iM+iA3A7zKPC/XdeFtH/H4j5Xoyc7xZ1FWxsmJPRkPQ6zj QJKOMl0bhk4Knk7W3Eeun3I/aKtcq1Pa4Tn+Q= 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=vPe1UH9mBt7FwL2xKkLRRhmHkqstuCMU jn6ZVxuo5e+g2ghClBW1VDqmZiyRafeWl8blunjWXt4pegfADwToaTMmwz1pIfsL O4waD9oWfBlRx2QBxDJWXBKiB7GH316TZjSjwJDmkbawtfMKSPweaieETVOC4IfN 0sZwgg8S3gc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 71412A861F; Sun, 21 Mar 2021 13:31:27 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id EFFC6A861E; Sun, 21 Mar 2021 13:31:26 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Bagas Sanjaya Cc: git@vger.kernel.org Subject: Re: Blob hash of binary files in patches generated by git format patch show in full form instead of short form References: <499c9922-eb42-c2a8-b4b4-8e5197ea0fc6@gmail.com> Date: Sun, 21 Mar 2021 10:31:26 -0700 In-Reply-To: <499c9922-eb42-c2a8-b4b4-8e5197ea0fc6@gmail.com> (Bagas Sanjaya's message of "Sun, 21 Mar 2021 20:05:39 +0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 43E27AD6-8A6B-11EB-9A71-D152C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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.