From patchwork Wed Jun 28 16:28:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adam Majer X-Patchwork-Id: 13296046 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DB0DEB64DA for ; Wed, 28 Jun 2023 16:28:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231221AbjF1Q2y (ORCPT ); Wed, 28 Jun 2023 12:28:54 -0400 Received: from c2.zombino.com ([65.108.93.176]:37660 "EHLO mail.zombino.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231910AbjF1Q2a (ORCPT ); Wed, 28 Jun 2023 12:28:30 -0400 Received: from [192.168.1.232] (port-92-195-193-117.dynamic.as20676.net [92.195.193.117]) by mail.zombino.com (Postfix) with ESMTPS id A2CBB3E98D for ; Wed, 28 Jun 2023 16:28:28 +0000 (UTC) Message-ID: <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com> Date: Wed, 28 Jun 2023 18:28:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 From: Adam Majer Subject: SHA256 support not experimental, or? To: git@vger.kernel.org Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi all, Is sha256 still considered experimental or can it be assumed to be stable? The usecase here is we are planning on moving to sha256 repositories mostly due to integrity guarantees, hypothetical or otherwise. What is important is not the initial interop challenges with sha1 repos, but whether the on-disk format will remain compatible with future versions of git. At minimum, the on-disk format would be converted by some future version(s) of git into another one and not be an end-of-the-road because it was "experimental" where dataloss is an implied risk. Attached is a patch that removes the scary text, if indeed sha256 should be viewed as stable. Cheers, - Adam Signed-off-by: Adam Majer --- Documentation/git.txt | 4 ++-- Documentation/object-format-disclaimer.txt | 8 ++------ 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index f0cafa2290..7c150a473c 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -553,8 +553,8 @@ double-quotes and respecting backslash escapes. E.g., the value If this variable is set, the default hash algorithm for new repositories will be set to this value. This value is ignored when cloning and the setting of the remote repository - is always used. The default is "sha1". THIS VARIABLE IS - EXPERIMENTAL! See `--object-format` in linkgit:git-init[1]. + is always used. The default is "sha1". + See `--object-format` in linkgit:git-init[1]. Git Commits ~~~~~~~~~~~ diff --git a/Documentation/object-format-disclaimer.txt b/Documentation/object-format-disclaimer.txt index 4cb106f0d1..dccee9c400 100644 --- a/Documentation/object-format-disclaimer.txt +++ b/Documentation/object-format-disclaimer.txt @@ -1,6 +1,2 @@ -THIS OPTION IS EXPERIMENTAL! SHA-256 support is experimental and still -in an early stage. A SHA-256 repository will in general not be able to -share work with "regular" SHA-1 repositories. It should be assumed -that, e.g., Git internal file formats in relation to SHA-256 -repositories may change in backwards-incompatible ways. Only use -`--object-format=sha256` for testing purposes. +Note: SHA-256 repository will in general not be able to +share work with "regular" SHA-1 repositories. -- 2.41.0