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-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 8C7A51F506 for ; Wed, 21 Sep 2022 21:01:27 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=skydio.com header.i=@skydio.com header.b="MzAdc7uk"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229873AbiIUU7y (ORCPT ); Wed, 21 Sep 2022 16:59:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230223AbiIUU7m (ORCPT ); Wed, 21 Sep 2022 16:59:42 -0400 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 143CB2F3A2 for ; Wed, 21 Sep 2022 13:59:38 -0700 (PDT) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-3454e58fe53so78470047b3.2 for ; Wed, 21 Sep 2022 13:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skydio.com; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=eqHJtNkPLFQRS0tm2+YKNr3ARfIHD/xvYGIHox4ljFQ=; b=MzAdc7ukqLWwNkUPQNjK6dCj8wraQPO4Pe1xF9AXx5U9PDUz6WQPWMNcJCfifKFlFR CG7KU1LTPfq8XXW6icn6h/h4XJudrbG08fTeWteI6iaAme5quez92QnwK71nvUYHWP2E DbQuNKi0RhugGuVA8mfMwSH03qWuz/xVi4rrPGbI3K785KL6X32JMew5j8yYHk2shxvS fvZLcdlBR4X6H3E2YUn9WA30N+i9wfJmj9tvXxYEavMqU7ndMp976oRyQZ/vaSk359WX dnco9RBNTAvEvmAK7YfVuGio2HQ0gAUKbEBrD9Z2GWfZc1YMbC3+AFmRmfgVoPYljlNw uOlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=eqHJtNkPLFQRS0tm2+YKNr3ARfIHD/xvYGIHox4ljFQ=; b=rKmdphdaz3g8361IBZW4LzrkSTY9Mf2VYyX3gfKHgsR8HMqyf9FCFGZTxkOT5rYapB DLqWLCYWRxAqQ0w/QCBkGcYC7/oZwgjXwrvwQ6gJ2gkseoKln1lex4u0yKH8QwnlfEI7 YwFOl8F7N0GQFGlsGztG9RJd1Q3za5j4DVNV0UObxppTZdO+6XA0rRIACHCMj7sd6RR+ 8uwZj+Lik9MhB91FzUyTNjhxjzH6jdaUqItG6LWfgDFwJRsQQdkkMTZY4hEcPPHbZQxN K/hDlA9wU0faOdtkVVznSwFAZd4l1vT8IXG3OqXU3bgNn7NKcYL0aszN/Ev2yPzJa/fU peuQ== X-Gm-Message-State: ACrzQf2WyJ7OcNPLT6fP3DwXtfwORk1F/ORkdCU1NhlTl2uIU00Z9SA7 P9hp/0NNKlCF2c7J+iIPbF4q2VUV/EHatMCh3fLUIw== X-Google-Smtp-Source: AMsMyM7LG9xc3ux5MN187DzPbStEdYy6VODYLKKCyXgPuqh2WB9COVxe6s0lXSN8phSbUXDvTylsgWhxXxsxIhYebsA= X-Received: by 2002:a0d:fac2:0:b0:349:f1d4:8b1e with SMTP id k185-20020a0dfac2000000b00349f1d48b1emr158749ywf.456.1663793977592; Wed, 21 Sep 2022 13:59:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerry Zhang Date: Wed, 21 Sep 2022 13:59:26 -0700 Message-ID: Subject: Re: [PATCH 0/2] update internal patch-id to use "stable" algorithm To: Junio C Hamano Cc: Jerry Zhang via GitGitGadget , git@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Wed, Sep 21, 2022 at 12:16 PM Junio C Hamano wrote: > > "Jerry Zhang via GitGitGadget" writes: > > > Internal usage of patch-id in rebase / cherry-pick doesn't persist > > patch-ids, so there's no need to specifically invoke the unstable varia= nt. > > > > This allows the unstable logic to be cleaned up. > > While all of that may be true, two things are not explained. > > * Why does "unstable" need to be "cleaned up"? Is that too dirty > in what way? > > * If internal usage does not persist patch-ids generated by the > machinery, why is it bad to be using the unstable variant? A > na=C3=AFve expectation would be to make sure you use stable one if you > want a future recomputation to give you the same result, but the > opposite does not have to be always true. > Fair questions. My broad view is that less code and fewer code paths is better for readability and testing. This isn't a massive impact but it's not theoretical either -- as seen in patch 1 in this series I caught a bug in stable + binary files because of this change. Previously stable patch ids were only used in "git format-patch" and so this corner case was missed, but this becomes less likely if rebase + cherry-pick + format-patch were all on the same scheme.