Re: [PATCH 0/2] update internal patch-id to use "stable" algorithm
On Wed, Sep 21, 2022 at 12:16 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
>
> "Jerry Zhang via GitGitGadget" <gitgitgadget@gmail.com> 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 variant.
> >
> > 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ïve 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.
Jerry Zhang <jerry@skydio.com>